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1.  INTRODUCTION 

RED  is  a  programming  language  designed,  in  accordance  with  the  DoD  "Steelman*  requirements,  for 
DoD  embedded  computer  applications.  The  language  combines  features  common  to  most  existing  high 
level  languages  with  new  capabilities  for  abstract  data  types,  exception  handling,  nultitasKing,  generic 
definitions,  and  access  to  machine-dependent  facilities. 

1.1  DESIGN  GOALS 

\  * 

The  RED  language  has  been  designed  to  reduce  the  total  life  cycle  cost  of  designing,  implementing, 

testing,  and  maintaining  programs.  For  sma."  and  medium  size  programs,  most  modern  high  level 
languages  are  similar.  However,  for  large  programs,  such  as  those  commonly  developed  for  embedded 
applications,  the  facilities  provided  by  a  language  become  crucial.  What  distinguishes  the  RED 
language  is  that  it  makes  it  easy  to  express  solutions  to  the  problems  encountered  when  developing 
large  programs.  I  j  tj  / 

Although  man^  factors  are  involved  in  judging  program  quality,  four  key  properties  that  will 
enhance  the  production  of  high  quality  programs  have  been  specifically  addressed  in  the  design: 

1>  Modularity  —  The  program  structure  must  be  clearly  modularized  so  as  to  facilitate  design  and 
maintenance. 

2)  Abstraction  —  It  must  be  possible  to  write  programs  in  terms  of  a  variety  of  abstractions  that 
are  appropriate  to  the  application  area,  and  in  a  notation  that  is  in  keeping  with  the  style  of  the 
notation  used  for  language-provided  abstractions. 

3)  Reliability  --  Coding  and  integration  errors  must  be  minimized  either  by  elimination  of  whole 
classes  of  errors  or  by  early  detection. 

4>  Effectiveness  --  The  program  must  address  the  real  problem  and  provide  an  effective  solution. 
Use  of  assembly  language  should  not  be  necessary. 

Modularity 

Cost  effective  program  development  and  maintenance  requires  a  modular  design.  The  RED 
language  provides  a  rich  set  of  features  for  creating  modules.  Some  of  the  kinds  of  modules 
supported  are: 

procedures 

functions 

tasks 

data  structures 
abstract  data  types 
schedulers 

multitasking  synchronization  schemes 
common  data  pools 

These  modules  may  be  nested  within  a  translation  unit  or  may  be  separately  translated  in  support  of  a 
large  cooperative  programming  effort.  Separate  translation  is  provided  as  an  integrated  feature  of 
the  language. 

The  RED  language  also  permits  modules  to  be  generalized  by  the  use  of  its  generic  facility.  For 
example,  a  sort  procedure  that  sorts  arrays  with  integer  components  can  easily  be  generalized  to  sort 
arrays  with  components  of  any  type. 
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Abstraction 

The  RED  language  allows  existing  language  notations  (e.g.,  operators)  and  features  (e.g.,  the  case 
statement)  to  be  extended  to  encompass  application  specific  abstractions.  Once  an  abstraction  has 
been  writte  .,  it  may  be  used  as  if  it  were  a  built-in  feature  of  the  language.  Although  application 
programmers  may  define  their  own  abstractions  (e.g.  procedures  and  abstract  data  types),  many 
centrally  defined  facilities  (e.g.  libraries,  common  routines  and  data,  real  time  schedulers)  will  be 
written  by  systems  progr  a, Timers.  For  these  kinds  of  abstractions,  the  language  provides  an  extensive 
set  of  advanced  features  intended  mainly  for  use  by  systems  programmers.  Once  an  abstraction  is 
defined  by  a  systems  programmer,  application  programmers  can  use  the  abstraction  without  having  to 
understand  the  advanced  features  used  in  its  implementation. 

Although  the  presence  of  advanced  facilities  in  RED  increases  the  apparent  complexity  of  the 
language,  it  actually  decreases  the  complexity  of  the  overall  programming  process.  Application 
programmers  will  be  able  to  use  more  appropriate  abstractions  rather  than  having  to  work  out  less 
effective  and  less  maintainable  solutions  to  their  problems. 

Reliability 

The  RED  language  is  designed  to  aid  the  programmer  in  the  production  of  reliable  programs. 
Particularly  dangerous  language  features  have  been  avoided.  The  language  is  fully  type  checked 
including  the  interfaces  between  separately  translated  modules.  Extensive  checking  for  error 
conditions  is  included;  whenever  possible,  the  checking  is  done  during  translation  rather  than  at 
runtime.  Facilities  are  also  provided  for  detecting  and  handling  runtime  errors.  Assertions  may  be 
specified  at  any  on'nt  in  a  program,  as  an  aid  to  program  verification  and  as  a  way  of  detecting 
runtime  errors.  cases  where  efficiency  is  an  overriding  consideration,  users  can  suppress  the 

generation  of  code  fc  -ecting  runtime  errors. 

The  scope  rule  -ther  with  the  capsule  and  expose  declarations,  allow  users  to  completely 
ontrol  the  regions  c  program  over  which  names  are  known. 

Effectiveness 

The  RED  language  provides  direct  and  convenient  ways  of  dealing  with  real  problems  that  have 
traditionally  been  either  difficult  or  impossible  to  handle  within  a  high  level  language.  This  means  that 
users  will  not  have  to  resort  to  assembly  language  to  solve  these  problems.  The  RED  language 
provides: 

1)  Access  to  machine-dependent .  features  --  Facilities  include  the  ability  to  specify  physical 
representations,  to  access  special  memory  addresses,  to  do  hardware  level  I/O,  and  to  handle 
hardware  interrupts. 

2)  Control  over  all  aspects  of  multitasking  --  Users  can  define  their  own  schedulers  and 
synchronization  schemes.  Both  multiprocessor  systems  with  shared  memory,  as  well  as 
distributed  systems,  can  be  supported. 

3)  Control  over  storage  management  --  Users  can  select  a  d,namic  storage  management  strategy 
that  is  appropriate  to  their  application.  In  particular,  applications  which  require  dynamic 
storage  management  are  not  forced  to  pay  the  price  of  garbage  collection,  but  can  choose 
alternative  methods. 
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1.2  SEMANTIC  FRAMEWORK 

This  section  discusses  some  of  the  key  concepts  which  form  the  semantic  framework  for  the  RED 
language. 

Scope  Rules 

A  program  consists  of  a  nested  set  of  scopes.  When  a  name  is  used,  a  local  definition  is 
referenced  if  one  exists;  otherwise,  a  definition  is  sought  for  in  enclosing  scopes.  There  are  two  basic 
kinds  of  scopes:  open  scopes  and  closed  scopes.  Closed  scopes  differ  from  open  scopes  in  that 
names  of  variable  definitions  in  enclosing  scopes  may  not  be  used  unless  they  are  explicitly  imported. 

A  capsule  is  a  scope  with  special  properties.  Definitions  within  a  capsule  are  explicitly  exported 
to  those  scopes  which  expose  the  capsule.  Capsules  are  also  the  unit  of  separate  translation. 
Definitions  exported  from  one  translation  unit  can  be  exposed  in  other  translation  units. 

Immediate  and  Deferred  Declarations 

Declarations  are  divided  into  two  groups:  immediate  declarations  (e.g.,  a  variable  declaration)  and 
deferred  declarations  (e.g.,  a  Drocedure).  Immediate  declarations  are  elaborated  when  they  are 
encountered,  while  deferred  declarations  are  elaborated  t  nly  when  they  are  explicitly  invoked. 

Deferred  declarations  may  have  parameters,  may  be  overloaded,  and  may  be  generic;  immediate 
declarations  may  not. 

Deferred  declarations  are  closed  scopes;  immediate  declarations  are  not  scopes  at  all. 

A  body  can  contain  declarations  as  well  as  statements.  In  a  body,  any  declaration  can  appear 
before  the  statements;  deferred  declarations  are  also  permitted  to  appear  after  the  statements.  All 
compound  declarations  (i.e.,  those  containing  bodies)  are  deferred  declarations. 

Types  and  Subtypes 

Data  items  (e.g.,  variables)  have  two  kinds  of  properties:  those  which  must  be  known  during 
translation  (type  properties)  and  those  which  must  be  known  when  a  data  item  is  created  (constraint 
properties).  A  type  consists  of  a  type  name  and  the  type  properties.  A  subtype  consists  of  a  type 
plus  the  constraint  properties.  The  following  are  types: 

I  NT 

STRINGCASCII] 

RECORD tc  :  INT,  b  :  STRINGtASCIIj] 

The  following  are  subtypes: 

INT { 1 . . 10 } 

STRINGCASCII]  (5) 

RECORD fa  ;  INH0..1),  b:STRING[ASCII]  <j)3 

Note  that  type  properties  are  always  enclosed  in  C  3,  while  constraint  properties  are  always  enclosed 
in  (  ). 

Subtypes  are  always  specified  for  declared  variables.  For  formal  parameters  and  function  results, 
either  a  type  or  a  subtype  is  specified.  A  formal  parameter  which  specifies  a  type  can  have  actual 
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parameters  with  any  subtype  of  that  type. 

Since  types  consist  only  of  information  known  at  translation  time,  alt  type  checking  (e.g.,  checking 
that  the  type  of  an  actual  parameter  is  the  same  as  the  type  of  the  corresponding  formal  parameter) 
is  done  during  translation."  Types  are  compared  by  comparing  their  "extended  name"  (i.e.,  their 
Identifier  plus  their  type  properties).  Type  checking  does  not  involve  structural  equivalence  (i.e., 
comparison  of  type?  which  are  recursive). 

In  addition  to  the  rich  set  of  built-in  types,  users  can  also  define  their  own  types  in  one  of  two 
ways:  as  "data  structuies"  or  as  "abstract  types".  A  data  structure  is  an  abbreviation  for  a 
composition  of  language  types.  For  example, 

ABBREV  r  :  RECORDfa  :  INTO.. 10), 

b  :  STRINGtASCIIJ  (5)3; 

VAR  x  :  r; 
is  equivalent  to 

VAR  x  :  RECORDCa  :  INTO..  10), 

b  :  STRINGEASCII]  (5)3; 

An  abstract  type  is  a  user-defined  type  (which  is  different  from  all  other  types)  together  with  a  set  of 
procedures  and  functions  which  operate  upon  data  items  of  the  type.  For  example,  a  user  can  define 
a  STACK  type  together  with  the  PUSH  and  POP  operations. 

Multitasking 

Concurrent  elaborations  are  achieved  via  the  multitasking  facilities.  Tasks  are  like  procedures 
except  they  are  invoked  by  a  task  invocation  statement  to  produce  a  task  activation.  Activations  of 
the  task  are  elaborated  concurrently  with  the  invoker.  Each  activation  of  a  task  is  named  by  a  unique 
activation  variable. 

The  elaboration  of  multiple  tasks  is  unde  !he  control  of  a  scheduler.  In  addition  to  a  language 
defined  priority  scheduler,  users  can  also  define  their  own  schedulers.  The  particular  scheduler  that 
is  used  for  a  task  activation  is  selected  based  on  the  type  of  its  activation  variable. 

Task  activations  can  communicate  in  two  basic  ways:  via  shared  memory  or  via  message  passing. 
Mutual  exclusion  over  shared  memory  is  achieved  by  datalocks  (which  are  basically  boolean 
semaphores)  and  a  region  statement.  Message  passing  is  supported  by  mailboxes  (which  are  basically 
a  queue  of  messages).  A  multiway  wail  statement  is  available  which  permits  users  to  receive  a 
message  from  any  one  of  several  mailboxes.  Multiway  waits  on  sending  of  messages  are  also 
provided.  If  there  are  several  activations  waiting  to  enter  a  region  with  some  data  lock,  or  to  send  a 
message  to  a  mailbox,  or  to  receive  a  message  from  a  mailbox,  they  are  queued  in  first-in  first-out 
order. 

Users  can  define  their  own  synchronization  schemes.  This  can  be  achieved  either  by  defining 
these  schemes  based  on  datalocks  or  mailboxes  or  by  way  of  the  low-level  multitasking  facilities. 
Low-tsvel  multitasking  facilities  include  latches  (which  are  basically  spin-locks)  together  with  a 
standard  set  of  low-level  operations  which  are  used  to  describe  scheduling,  region  statements,  and 
multiway  waits.  One  important  property  of  user-defined  synchronization  is  that  a  particular  scheme 
can  be  defied  independent  of  any  particular  scheduler  (i.e.,  it  can  be  used  without  modification  with 
any  scheduler).  Timing  facilities  are  also  available  for  measuring  times  or  delaying  based  upon  either 
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Any  deferred  declaration  can  be  generic.  A  generic  declaration  is  a  generalized  form  from  which  a 
collection  of  different  instances  of  the  declaration  can  be  derived.  These  instances  are  produced 
during  translation.  Instances  differ  in  the  values  of  a  set  of  generic  parameters.  Generic  parameters 
may  be  types,  functions,  procedures,  tasks,  or  manifest  values. 

Generics  are  used  to  generalize  a  particular  deferred  declaration.  For  example,  a  generic  sort 
procedure  can  sort  arrays  with  components  of  any  type.  A  generic  stack  type  includes  stack  types 
which  can  have  a  component  type  (e.g.,  STACK  [INT3,  STACK  [STRING  [ASCII] 3>.  A  generic 
integrate  procedure  can  integrate  any  function,  for  example,  from  floats  to  floats. 

Generic  declarations  allow  the  user  to  write  a  single  definition  which  is  specialized  (i.e., 
instantiated)  during  translation  for  several  specific  uses,  rather  than  having  to  write  a  separate 
definition  for  each  of  the  separate  uses. 

1.3  PROGRAMMING  CONSIDERATIONS 

The  characteristics  of  the  RED  language  discussed  above  represent  a  solution  to  the  problem  of 
providing  a  standard  language  for  military  software  production,  one  that  can  serve  all  applications 
without  ignoring  the  special  requirements  of  each.  The  solution  presented  here  is  based  heavily  on 
the  data  abstraction  capabilities  that  permit  the  same  language  to  be  specialized  as  needed,  but  in  a 
form  that  is  invisible  to  the  applications  programmer  and,  perhaps  more  importantly,  .to  the 
maintenance  programmer.  Changes  required  can  be  implemented  in  terms  of  underlying  definitions  so 
that  most  often  programs  need  not  be  changed  at  all  in  order  to  operate  differently.  Such  underlying 
modifications  can,  further,  affect  many  applications  programs,  so  that  the  maintenance  effort  is 
substantially  reduced  along  with  maintenance  costs. 

In  order  to  provide  comprehensive  support  within  the  context  of  one  high-level  language,  the  RED 
language  necessarily  includes  complex  features  that  will  neither  be  needed  or  necessarily  understood 
by  all  programmers.  By  separating  out  these  complex  features,  it  has  been  possible  to  retain  a  core 
of  basic  programming  facilities  that  are  similar  to  most  other  languages  and,  thus,  easy  to  learn  and 
use,  yet  flexible  enough  so  that  sophisticated  applications  can  be  expressed  using  only  these  basic 
facilities. 


6 


Section  1.4 


RED  LRM  8  March  1979 


1.4  OVERVIEW  OF  THE  LANGUAGE  REFERENCE  MANUAL 

This  LRM  is  divided  into  four  major  parts: 

GREEN  (Chapters  1-7)  -  Basic  Language  Features.  The  features  described  here  will  be 

needed  -by  all  users.  This  part  of  the  language  Is  roughly  equivalent  to  the 
PASCAL  language.  Simple  programs  can  be  written  using  only  these  features. 

YELLOW  (Chapters  8-11)  -  Intermediate  Language  Features.  The  features  described  here 

will  be  needed  by  most  users. 

RED  (Chapters  12-14)  -  Advanced  Language  Features.  The  features  described  here 

are  provided  mainly  for  use  by  systems  programmers,  rather  than  by  application 
programmers. 

BLUE  Appendices,  Index. 

The  division  into  basic,  intermediate,  and  advanced  parts  is  only  approximate.  Although  most 
features  described  in  a  chapter  belong  in  the  part  in  which  the  chapter  is  placed,  some  features 
discussed  may  conceptually  belong  in  some  other  part.  For  example,  the  type  declaration  is 
intermediate  rather  than  basic,  some  aspects  of  the  use  of  generics  are  advanced  rather  than 
intermediate,  and  definition  of  operators  is  intermediate  rather  than  advanced. 

1.5  MANUAL  LAYOUT 

This  document  is  a  language  reference  manual,  designed  to  provide  the  user  with  a  complete 
description  of  the  format,  usage  and  effects  of  all  language  features.  Basic  lexical  elements  of  the 
language  are  described  first  (Chapter  2).  Subsequent  chapters  present  the  various  language 
constructs. 

Each  section  of  the  manual  follows  the  same  basic  five-part  form  given  below,  although  any  of  the 
five  parts  may  be  omitted  when  it  is  not  applicable. 

1)  Diagrams  -  A  flow  diagram  format  (described  in  Section  1.6)  is  used  to  specify  the  form  for 
lexical  elements  and  the  syntax  for  language  constructs. 

2)  Informal  Descrip*!on  -  The  text  immediately  following  the  diagrams  informally  describes  the 
purpose,  use  and  meaning  of  the  lexical  element  or  language  construct. 

3)  Rules  -  The  heading  RULES  indicates  that  the  following  text  gives  rules  completely  defining  the 
meaning  of  the  lexical  element  or  language  construct,  that  are  not  already  given  by  the  syntax. 

4)  Notes  -  The  heading  NOTES  indicates  that  the  following  text  describes  how  the  lexical  element 
or  construct  interacts  with  other  parts  of  the  language.  Rules  from  other  sections,  which  are 
relevant  to  this  lexical  element  or  construct,  may  be  summarized. 

5)  Examples  -  The  heading  EXAMPLES  precedes  sample  coding  sequences  that  illustrate  the  various 
valid  forms  of  lexical  elements  or  the  use  of  language  constructs. 

1.6  FLOW  DIAGRAMS 

Flow  diagrams  are  used  in  this  manual  to  specify  all  the  forms  of  a  single  lexical  element  or 
language  construct.  By  tracing  a  path  through  a  diagram,  an  instance  of  the  element  or  language 
construct  represented  by  that  diagram  may  be  produced.  There  is  a  path  through  a  diagram  for  every 
valid  instance.  These  diagrams,  together  with  the  rules,  provide  a  complete  description  of  the 
language.  Rules  for  interpreting  these  diagrams  are  given  below. 
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1.6.1  FLOW  DIAGRAMS  FOR  LEXICAL  ELEMENTS 


RULES 

1>  Each  d.agram  defines  the  forms  for  a  particular  lexical  element  (see  Chapter  2>.  The  name  of 
the  element  being  defined  appears  in  the  oval,  (T),  at  the  upper  left  of  the  diagram. 

2)  The  diagram  identifier,  the  letter  in  the  upper  right  hand  corner,  (2),  is  associated  with  this 
specific  diagram.  An  index  of  diagram  identifiers  may  be  found  in  Appendix  F  .  In  the  example 
illustrated,  the  syntax  diagram  defines  ail  possible  forms  of  an  identifier  token. 

3)  Boxes  with  circular  ends,  (5),  represent  lexical  elements  or  characters  from  which  they  are 
constructed. 

4)  If  the  rounded  box  represents  an  element  defined  in  another  syntax  diagram,  a  letter  above  the 
rounded  box  is  the  diagram  identifier  associated  with  that  element. 

5)  To  generate  forms  of  the  element,  the  diagram  is  followed  from  left  to  right,  from  box  to  box, 
starting  at  the  point  of  the  junction  of  the  definition  box,  (4).  and  ending  when  the  end  of  the 
path,  (§),  is  reached. 

6>  When,  in  following  a  diagram,  a  black  dot,  (J),  is  reached,  any  of  the  paths  leaving  the  dot  may 
be  followed. 

7>  It  is  not  legal  to  "back  up"  along  a  convergent  path,  (7). 

8)  When  a  box  is  encountered,  the  element  it  contains  is  added  to  the  right  o.‘  the  preceding 
element.  For  example,  the  path  shown  by  the  dotted  line,  (S),  generates  the  sequence  "letter 
letter  underscore  letter"  (e.g.,  AB_C). 
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1.6.2  SYNTAX  DIAGRAMS  FOR  LANGUAGE  CONSTRUCTS 


The  diagrams  defining  language  constructs  are  similar  to  those  for  lexical  elements  with  the 
fallowing  differences; 

10  The  name  of  the  language  construct  being  defined  appears  in  a  rectangular  box,  (T),  in  the 
upper  left-hand  corner.  The  illustrated  example  defines  the  syntax  of  a  statement. 

2)  The  diagram  identifier,  (|),  for  language  construct  diagrams  is  an  integer.  An  index  of  diagram 
identifiers  may  be  found  in  Appendix  F  . 

3)  Boxes  with  circular  ends,  such  as,  (3),  represent  lexical  elements;  reserved  words  appear  in 
capital  letters.  A  letter  above  the  box,  (5),  identifies  the  diagram  in  which  the  element  is 
defined. 

4)  Rectangular  boxes  within  the  diagram,  such  as  (§),  represent  language  constructs  defined 
elsewhere.  If  a  number  appears  above  the  box,  the  construct  is  defined  in  the  diagram 
identified  by  that  number. 

5)  Following  a  path  through  a  grammar  syntax  diagram  produces  an  instance  of  the  construct. 
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2.  LEXICAL  STRUCTURE 

2.1  CHARACTER  SET  AND  TRANSLATOR  INPUT 

Programs  are  composed  of  any  sequence  of  characters  from  the  95-character  ASCII  or  basic 
55-character  set.  Any  program  can  be  written  using  only  the  55-character  set  given  below.  Rules 
for  converting  from  the  95-character  ASCII  set  to  the  55-character  set  are  given  In  the  description 
for  specific  token's  and  token  separators. 

RULES 


No  distinction  is  made  between  upper  and  lower  case  letters  except  within  a  string  literal 


Basic  55-Character  Set 

7.&'<  )*+,-./:;<=>? 

0123456789 

ABCBEFGHIJKLMNOPQRSTUVWXYZ_ 
95-Character  ASCII  Set 

All  characters  in  the  basic  55-character  set  plus 

M  I )~ 

abcdefghi jklmnopqrstuvwxyz 

NOTES 


Thia  document  utaa  lha  95-chiractar  ASCI!  aat  to  daacrka  tba  tanfutfa. 
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2.2  TOKENS  AND  TOKEN  SEPARATORS 


A  token  is  the  basic  component  u'sed  to  build  all  constructs  of  the  language.  It  is  an  indivisible 
lexical  unit  that  is  interpreted  as  a  complete  'word'  by  the  translator.  A  token  separator  is  required  in 
some  cases  between  tokens  and  can  be  used  otherwise  to  improve  readability.  A  token  or  token 
separator  is  composed  of  a  contiguous  sequence  of  characters. 

RULES 

Input  text  is  organized  into  lines,  each  of  which  is  composed  of  tokens  and  token  separators.  No 
token  or  token  separator  can  extend  over  mors  than  one  line  of  text.  An  end  of  line,  eol,  is  a  token 
separator. 

A  token  separator  must  appear  between  any  two  adjacent  tokens,  unless  one  of  the  tokens  is  a 
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special  symbol  or  an  operator  symbol  <such  as  <)  which  does  not  have  the  form  of  an  identifier  (e;g., 
AND).  Ono  or  more  token  separators  may  appear  between  any  two  tokens. 

EXAMPLES 

PERSON. WOMAN. ADA 

NOT  A  %  token  separator  required 

F  (  A  :  INT  )  ; 

F(A:INT) ; 

END  CASE  %  token  separator  required 

WHEN  A=>  %  token  separator  required 

2.3  TOKENS 

2.3.1  RESERVED  WORDS 

Reserved  words  have  a  fixed  meaning  within  the  syntax  of  the  language. 

RULES 


The  following  are  reserved  words: 


ABBREV 

END 

ABNORMAL 

EXCEPTION 

ALL 

EXIT 

ALLOC 

EXPORTS 

ASSERT 

EXPOSE 

BEGIN 

EXTERNAL 

BY 

FOR 

CAPSULE 

FROM 

CASE 

FUNC 

CONST 

GENERIC 

CREATE 

GOTO 

DO 

GUARD 

ELSE 

IF 

ELSEIF 

IMPORTS 

NOTES 

Reserved  word*  may  not  ba  redefined. 


LOCATION 

RENAMING 

NAMED 

REP 

NEEDS 

REPEAT 

NEW 

RERAISE 

NONE 

RETURN 

OUT 

SUBTYPE 

OF 

TASK 

PRAG 

THEN 

PROC 

TO 

PTR 

TYPE 

RAISE 

VAR 

READONLY 

WAIT 

REVERSE 

WHEN 

REGION 

WHILE 

No  distinction  it  meda  in  tha  uaa  of  upper  or  lowar  cat*  character*  in  •  raaarvad  word:  thu*,  and,  End,  END,  *nd  snD  *ra  alt 
equivalent. 
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2.3.2  OPERATOR  SYMBOLS 

Operator  symbols  are  names  of  functions  which  are  invoked  with  a  special  prefix  or  infix  syntax 
(see  Section  5.2). 

RULES 


The  operator  symbols  are: 


** 

exponentiation 

*,  / 

multiplication,  division 

DIV,  HOD 

integer  division,  modulo 

+,  - 

addition,  subtraction,  prefix  plus  and  minus 

& 

concatenation 

=,  /=,  >,  >=,  <,  <  = 

relations 

IN 

set  membership 

OR 

or  (set  union), 

XOR 

exclusive  or  (set  symmetric  difference) 

AND 

and  (set  intersection) 

NOT 

logical  negation  (set  complement) 

NOTES 

Th*  definition  of  operator  symbol  nama*  it  diaeuiiad  in  Saciion  132. 

2.3.3  SPECIAL  SYMBOLS 

Special  symbols  are  tokens  which  have  special  meaning  in  the  syntax. 

♦ 

RULES 

The  table  below  lists  the  special  symbols  and  their  uses. 

.  component  selection,  attribute  inquiry 

( )  parenthesization,  subscripting,  parameter  lists 

t]  type  properties,  translation  time  properties,  constructors 

f  list  separation 

:  name  separation,  goto  labels 

;  statement  terminator,  end  of  compound 

declaration  headers 

=  >  alternative  indication,  function  result 

. .  ranges 

#  constant  resolution 

:=  assignment 

All  of  the  special  symbols,  except  C,  ],  and  #,  consist  of  characters  exclusively  from  the  55-character 
set.  The  following  55-character  alternates  are  provided. 

<<  55-character  form  of  [ 

>>  55-character  form  of  ] 

: :  55-character  form  of  # 
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2.3.4  IDENTIFIERS 


An  identifier  is  a  name  which  is  associated  with  a  language  construct  by  a  definition  (see  Section 
3.5). 

RULES 

Reserved  words  and  operator  symbols  (e.g.,  AND)  may  not  be  used  as  identifiers. 

All  characters  in  an  identifier,  including  underscore,  are  significant. 

NOTES 

No  dietinction  ii  mede  in  Hie  u»e  of  upper  or  lower  et«#  chereelert  in  »n  Identifier  (e.f.,  Abe,  ebc,  end  ABC  ere  ell  equivalent). 


EXAMPLES 

THIS_IS_A_VERY_LONG_NAME 

Th  is_is_a_very_long_name  X  same  as  above 

VELOCITY 

UNIT_01 

REAR_UNIT_01 

THIS_IS _ ILLEGAL  X  two  underscores  together 

AS_IS_THIS_  X  illegal 
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2.3.5  LITERALS 


Literals  are  used  to  specify  values  for  some  built-in  types  and  for  user-defined  indirect  types  (see 
Section  4.4.3). 

RULES 

The  values  of  ail  literals  are  Known  at  translation  time. 

The  rules  for  resolution  of  the  type  and  subtype  of  a  literal  are  described  In  Section  5.7. 

NOTES 


Th#  foHowirtg  sections  dsacrib*  specific  Merits. 


deaerfeed  in  Section*  5.'/  and  135. 


I 


Uiar-dafinad  literal*,  which  ir*  l*nf u»(t  construct*  rather  than  tokens,  ara 
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2.3.6  NUMERIC  LITERALS 


Numeric  literals  specify  integer  values  for  the  INT  type  and  floating  point  values  for  the  FLOAT 
type. 

RULES 

A  floating  point  literal  in  E  form  is  interpreted  as  the  decimal  number  times  ten  to  the  integer 
value  following  E.  The  default  precision  of  a  floating  point  number  is  the  number  of  digits  preceding 
E,  minus  any  leading  zeros  to  the  left  of  the  decimal  point. 


16 

NOTES 


Section  2.3.6 


RED  LRM  8  March  1979 


Numeric  Literals  are  always  positive  valuss.  A  negative  litsral  is  obtained  by  preceding  the  liter el  with  the  prefix  minus 
operator.  This  operation  is  performed  at  translation  time. 

Bacause  a  float  literal  is  a  token,  blank*  may  not  appear  within  tha  float  literal. 

The  precision  of  a  float  literal  is  first  determined  by  eontaxt  and,  if  that  is  not  tufficiant,  the  default  precision  ie  used  («e@ 
Section  5.7). 

No  distinction  is  mads  In  tha  use  of  upper  or  lower  eats  a  in  a  float  literal. 

EXAMPLES 

1  « 

%  Integer  literals 
0 

2354 

%  floating  point  literals 
3.6E7  X  default  precision  2 

1.0E5  X  default  precision  2 

7.25  X  default  precision  3 

6.324e-6  X  default  precision  4 

0.0  X  default  precision  1 

0.012  X  default  precision  3 

2.3.7  ENUM  LITERALS 


An  enum  Literal  specifies  a  named ‘value  of  an  enumeration  type. 

NOTES 

The  same  enumeration  literal  may  appear  in  several  enumeration  type*.  For  example,  the  enumeration  literal  'ORANGE  may 
appear  simultaneously  in  the  ENUM  types  FRUIT  and  COLOR. 

Because  an  enum  literal  is  a  token,  no  blank  may  appear  between  the  apostrophe  end  the  Identifier. 

Because  the  envoi  literal  is  distinguished  by  sn  apostrophe,  the  Identifier  following  the  apostrophe  may  be  defined  In  the  came 
scope  (l.e.,  RED  may  be  the  name  of  a  variable  in  the  asm*  scope  in  which  'RED  is  sn  enum  literal). 

The  language  views  a  character  set  ss  sn  enumeration  type,  where  each  character  corresponds  to  an  enum  literal. 
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No  distinction  is  m»d«  in  uas  of  upper  or  lower  ctse  (•  j,  'RED,  'Red,  'red,  end  'reO  ere  ill  equivelent). 

EXAMPLES 


'RED 

'POSITIVE 
'ACTIVE 
1  LEFT-ALIGNED 


'Rlght^Al igned 

'RED'  X  illegal  closing  apostrophe 

'4TH  X  illegal  character  beginning  identifier 


2,3.8  STRING  LITERALS 


anv  character  except  or 


A  string  literal  specifies  a  value  of  a  STRING  type.  A  string  is  a  sequence  of  characters.  Each 
character  is  an  enumeration  literal.  If  a  string  includes  only  those  characters  in  the  95-character  set, 
the  special  literal  form,  string  Literal,  can  be  used.  A  string  literal  is  considered  to  be  a  shorthand 
form  for  the  concatenation  of  characters  defined  by  enum  literals;  e.g.,  "ABC"  is  considered  a 
shorthand  form  of 


'A  &  'B  &  'C 


RULES 


'  1  is  the  55-character  form  of  ". 
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•  NOTES 


A  string  literal  m»y  not  extend  over  out  line.  If  an  end  of  lino  it  found  before  lh*  terminating  quoit,  the  tiring  litoral  token  it 
terminated  and  an  error  montage  it  iscuad.  The  4  infix  operator  can  bt  used  to  obtain  t  long  tiring  by  concatenation. 

Upptr  or  lower  cea«  charactera  art  diatinguiahed  in  airinga;  e.g.,  "ABC"  it  not  equivalent  to  "*bc".  All  character#  In  the 
95-character  ASCII  tet  have  »  corresponding  enumeration  li'.wal  (defined  in  Appendix  C.15).  For  example,  alnee  ’Ibreeket  la  the 
enumeration  litoral  for  [  and  'number  the  enumeration  literal  for  e,  the  tiring 

"CA#B3" 

la  equivalent  to 

1  Ibracket  &  "A"  &  ’number  &  "B"  &  'rbracket 


INTERMETRICS  INC. 
EXAMPLES 


Section  2.3.8 


X  creating  a  string  too  long  for  a  single  line 

"VERY...  LONG.. -.STRING" 

&  "REST  OF  VERY  LONG  STRING" 

X  placing  carriage  return  and  line  feed 
%  at  the  end  of  a  string 
"ONE  LINE"  &  'CR  &  * LF 
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2.3.9  BOOLEAN  LITERALS 


A  boolean  literal  specifies  a  value  of  type  BOOL 


2.3.10  INDIRECT  LITERAL 


The  indirect  literal  NIL  specifies  that  value  of  an  indirect  type  (see  Section  4.4.3)  which  points  to 
no  dynamic  variable. 


A  comment  provides  program  documentation. 


RULES 

A  comment  is  terminated  by  the  end  of  the  line  on  which  it  appears.  Comments  are  ignored  by 
the  translator. 

2.4.2  PRAGMAT 


pragmats  supply  information  to  the  translator  which  does  not  affect  language  semantics.  Pragmats 
are  described  in  Appendix  B. 


I 

i 

1 

i 

! 
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3.  PROGRAM  STRUCTURE 

3.1  PROGRAM 


translation, 

u>'  1 1 


© 


54 


capsule  declaration 


A  program  consists  of  one  or  more  translation  units  which  may  communicate  with  each  other. 
Each  translation  unit  is  a  capsule  declaration.  Capsule  declarations  may  also  be  nested  within 
translation  units  and  are  described  more  generally  in  Chapter  8.  A  capsule  declaration  consists  of  a 
header,  a  body,  and  an  ending.  The  header  names  the  capsule  and  provides  an  exports  list  that  makes 
definitions  within  the  capsule  available  to  other  translation  units.  The  body  consists  of  a  sequence  of 
declarations,  statements,  and  assertions.  Declarations  provide  definitions  for  names,  statements  specify 
actions  to  be  performed,  and  assertions  specify  conditions  that  are  to  be  true  at  the  points  where  the 
assertions  appear.  The  ending  terminates  the  text  of  the  capsule  declaration. 

The  intent  of  a  program  is  realized  by  elaborating  the  program.  The  notion  of  elaboration  is 
meant  to  provide  a  general  way  of  describing  closely  related  translator  functions,  such  as  execution 
for  statements  and  evaluation  for  expressions.  Elaboration  can  apply  to  statements,  assertions, 
declarations,  and  expressions,  and  includes  translation-time  as  well  as  execution-time  activities.  The 
elaboration  of  a  compound  syntactic  unit  is  defined  in  terms  of  the  elaboration  of  its  constituent  units. 

In  the  simplest  case,  a  program  consists  of  just  one  translation  unit.  The  invocation,  initiated  by 
the  programming  system,  consists  of  elaboration  of  the  body  of  that  unit.  When  there  is  more  than 
one  translation  unit,  the  user  must  select  (via  the  programming  system)  a  particular  one  to  be  invoked 
as  the  main  capsule. 
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EXAMPLES 

CAPSULE  prime  EXPORTS  NONE; 

CONST  max  :*  100; 

*/.  this  program  prints  all  prime  numbers  that  are 
V.  less  than  or  equal  to  max 
VAR  numbers  :  ARRAY  INK 2.. max)  OF  EOOL 
:=  [2.. max  :  TRUE]; 

FOR  1  :  INT ( 2 . .max)  REPEAT 
IF  numbersd)  THEN 

VAR  j  :  INT<2*1  ..  max+1 )  :=  2*1; 

WHILE  j  <=  max  REPEAT 
numbers( 1 )  :=  FALSE; 
j  :=  j+1; 

END  REPEAT; 

END  IF; 

END  REPEAT; 

OPEN  (SYS_OUT,  "TTY”,  'NEW) 

WRITELN  ("PRIME  NUMBERS"); 

FOR  1  :  INK2 .  .max)  REPEAT 
IF  numbersd)  THEN 
WRITELN  (1); 

END  IF; 

END  REPEAT; 

CLOSE  (SYS_OUT,  'SAVE); 


END  CAPSULE  prime; 


A  body  consists  of  a  sequence  of  body  elements,  each  of  which  is  either  a  declaration,  a  statement, 
or  an  assertion.  A  body  is  used  where  a  related  sequence  of  body  elements  must  be  treated  as  a  unit. 
Statements  and  declarations  that  can  contain  bodies  are  known  as  compound  statements  and  compound 
declarations.  For  example,  one  possible  form  of  an  if  statement  is: 

IF  expression  THEN  bodyl  ELSE  body2  END  IF 

In  this  example,  bodyl  and  body2  specify  the  actions  to  be  taken  after  elaboration  of  the  expression 
yields  true  or  false,  respectively.  Depending  on  the  bodies  given,  the  actions  may  range  from 
elaboration  of  a  single  element  to  a  complex  sequence  of  actions. 

Empty  bodies  are  permissible;  this  is  useful  when  no  action  needs  to  be  taken. 
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RULES 

An  immediate  declaration  (see  Section  3.3)  must  precede  all  statements .  A  deferred  declaration 
(see  Section  3.3)  or  generic  declaration  (see  Section  11.3)  may  either  precede  or  follow  all  statements. 

Elaboration  of  a  body  consists  of  the  elaboration  of  all  body  elements  other  than  deferred  and 
generic  declarations.  The  elements  are  elaborated  in  the  sequence  in  which  they  are  written,  unless 
control  Is  transferred  by  an  exit,  return,  or  goto  statement. 

NOTES 

A  body  is  an  open  scope  (see  Section  3.5).  Declarations  end  goto  l»bel»  define  nemee  within  e  body. 

An  assertion  may  appear  at  any  point  in  the  eeqoenee  of  body  elements  ainee  it  may  be  uieful  before  or  after  either  e 
declaration  or  a  statement. 

Since  deferred  declarations  and  generic  declarations  are  aometimea  quite  long,  placinf  them  after  the  statements  often  make*  a 
program  more  readable.  Placement  of  deferred  declarations  can  be  determined  by  programming  etendarde  end  etyle  considerations. 
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3.3  DECLARATIONS 


declaration 


imnediate 

[declaration 


i)- 


r 


deferred 

declaration 


3.3 


5 


imediate  declaration 

6 

deferred  declaration 

rj 

69 

i 

generic  declaration  | 

J 

15 

variable  declaration 

\ 

16 

constant  declaration 

55 

capsule  invocation 

. 

declaration 

57 

J 

exception  declaration 


17 


abbreviation 

declaration 


© 
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type  declaration 


compound  declaration 
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compound 
I  declaration 


procedure  declaration 
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function  declaration 


© 
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caosule  declaration 


61 


task  declaration 


All  declarations  define  names.  There  are  two  basic  Kinds  of  declarations :  immediate  and  deferred. 
Immediate  declarations  are  elaborated  when  encountered  during  the  elaboration  of  a  body.  Deferred 
declarations  are  not  elaborated  when  first  encountered;  instead,  they  define  deferred  units  which  are 
elaborated  only  when  invoked  from  elsewhere. 

A  generic  declaration  stands  for  a  collection  of  deferred  declarations  and,  therefore,  is  not 
elaborated  when  encountered  (see  Section  11).  for  a  discussion  of  generics. 

NOTES 

Differences  between  immediate  and  deferred  declarations  are  listed  below. 


Immediate  declaration 
elaborated  when  encountered 
can  not  have  parameters 
must  appear  before  statements 

can  not  be  overloaded 

can  not  be  generic 

can  not  have  a  translation 
time  property  list 

are  not  compound 

are  not  scopes 


Deferred  declaration 

elaborated"  when  invoked 

can  have  parameters  (7.3) 

can  appear  either  before  or 
after  statements  (3.2) 

explicit  overloading  is  permitted  for 

all  except  types 

(11.2) 

can  be  generic  (1 1.3) 

can  have  a  translation  time 
property  list  (11.1.2) 

includes  all  compound  declarations 

are  closed  scopes<3.5) 


INTERMETRICS  INC.  Section  3.3 

Deferred  declarations  and  their  characteristics  are  summarized  below. 


Declaration 

Invocation 

Effect  of  Invocation 

procedure  (7.1) 

procedure  invocation 
statement 

performs  some  action 

function  (7.2) 

function  invocation 
primary 

produces  a  value 

task  (10.1) 

task  invocation 
statement 

an  activation  of  the  task 
is  elaborated  concurrently 

capsule  (8.1) 

capsule  invocation 
declaration 

makes  exported  definitions 
visible 

abbreviation  (4.4.1) 

abbreviation 

invocation 

produces  an  abbreviated 
type  or  subtype 

type  (4.4.2) 

user-defined  subtype 

produces  a  subtype  of 
a  user-defined  type 

EXAMPLES 

1)  Immediate  declarations. 

VAR  flag  :  BOOL  :=  TRUE; 

CONST  pi  :=  3.14159; 

EXCEPTION  stack_underflow,  stack_overf low; 

EXPOSE  ALL  FROM  compool; 

2)  Deferred  declarations. 

ABBREV  max_1nt  :  INT(m1n, .max) ; 

TYPE  complex  <n,m  :  FLOAT)  :  RECORDCr,  1  :  FLOATU0,  n..m)J; 

PROC  complex_complement  (VAR  x  :  complex); 
x .  1  : =  -x .  1 ; 

END  PROC  complex_complement; 

FUNC  even  (1  :  INT)  =>  BOOL; 

RETURN  (1  MOD  Z)  =  0; 

END  FUNC  even; 

TASK  reader; 

END  TASK  reader; 

CAPSULE  compool  EXPORTS  ALL; 

%  variable  declarations 


END  CAPSULE  compool; 
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3)  Generic  declaration. 

GENERIC  t  :  TYPE  NEEDS  :=  (t,t>;  X  needs  assignment 

X  operator 

X  swap. for  any  type 
PROC  swap(VAR  a,b  :  t); 

CONST  c  a; 
a  :=  b; 
b  :=  c; 

END  PROC  swapj 


3.4  ASSERTIONS 


assertion 

© 

26 

expression 

An  assertion  specifies  a  condition  which  will  be  true  when  the  assertion  is  elaborated.  Assertions 
are  used  to  make  programs  easier  to  read  and  maintain,  to  provide  information  useful  to  an  optimizing 
compiler,  and  to  provide  checkpoints  for  formal  and  informal  verification  of  correctness. 

RULES 

The  expression  must  have  type  BOOL.  Elaboration  of  an  assertion  consists  of  testing  the  value  of 
the  expression  and,  if  the  expression  is  false,  raising  the  X_A$SERT  exception. 

NOTES 


An  tsaertion  does  no!  necessarily  imply  runtime  checking.  If  the  condition  c«n  be  checked  during  translation,  then  object  cod* 
need  not  be  generated  for  it  If  an  assertion  ia  known  to  be  false  at  translation  time,  e  warning  is  issued.  A  pregmet  is  sveilable  for 
suppressing  the  X_ASSERT  exception  (see  Appendix  B). 
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FUNC  sqrt  (a  :  FLOAT)  =>  FLOAT; 

ASSERT  a  >  0.0; 

ENDFUNC  sqrt;" 

PROC  fun_d1v1de  <a,b  :  INT,  OUT  c,d  :  INT) 

ASSERT  a>=0  AND  b>0; 

VAR  x  :  INT(0..a)  :=  0; 

VAR  y  :  INT(0..a)  :=  a; 

ASSERT  b*x+y  =  a; 

WHILE  y  >=  b  REPEAT 
ASSERT  b*x+y  =  a; 
x  :  =  x+1; 
y  :=  y-b; 

END  REPEAT; 

ASSERT  (b*x+y  =  a)  AND  y<b; 


c  :=  x  ; 
d  :=  y  ; 

ASSERT  (b*c+d  =  a)  AND  0<=d  AND  d<b; 


END  PROC  fu11_d1v1de; 
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3.S  NAMES  AND  SCOPES 

A  name  is  either  an  identifier  or  a  definable  symbol  (see  Section  13.2).  Definable  symbols  are 
used  only  to  refer  to  builtrin  operations  or  to  functions  and  procedures  that  provide  additional 
definitions  for  built-in  operations. 

Every  use  of  a  name  must  have  a  corresponding  definition:  definitions  of  names  are  never  created 
by  default.  There  are  several  forms  of  definition,  including  declarations ,  formal  parameters,  and  goto 
labels.  A  name  may  have  more  than  one  definition;  when  this  occurs,  it  must  be  possible  to  associate 
each  use  with  the  appropriate  definition.  The  association  is  governed  by  the  scoping  rules. 

A  scope’  is  a  syntactic  form  in  which  names  may  be  defined.  An  open  scope  is  a  scope  in  which  all 
definitions  in  the  enclosing  scope  are  known,  provided  that  those  definitions  do  not  conflict  with  a 
local  definition  of  the  open  scope.  A  closed  scope  differs  from  an  open  scope  in  that  matching 
identifiers  (the  tfc  get  of  an  exit  statement )  and  goto  labels  (see  Section  6)  from  the  enclosing  scope 
are  never  available  and  variables  from  the  enclosing  scope  are  available  only  when  explicitly  listed  in 
an  imports  list. 

RULES 

All  deferred  declarations  (see  Section  3.3)  are  closed  scopes.  Bodies  (see  Section  3.2),  compound 
statements  (see  Section  6),  and  generic  declarations  (see  Section  11.3)  are  open  scopes. 

Everything  in  one  scope  that  is  outside  any  scope  contained  within  it,  is  called  local  to  that  scope. 
For  all  non-deferred  definitions,  two  definitions  are  considered  to  conflict  if  the  same  name  is 
associated  with  both.  Conflicting  definitions  local  to  the  same  scope  are  not  permitted.  Deferred 
declarations  with  the  same  name  do  not  necessarily  conflict  (see  Section  11.1). 

The  definitions  which  are  Known  in  a  scope  are: 

a)  all  local  definitions;  and 

b)  each  definition  which  is  known  in  the  enclosing  scope,  is  available,  and  does  not  conflict  with  a 
local  definition. 

For  open  scopes,  all  definitions  known  in  the  enclosing  scope  are  available.  For  closed  scopes,  all 
definitions  known  in  the  enclosing  scope  are  also  available,  with  the  following  two  exceptions: 

a)  goto  labels  and  matching  identifiers;  and 

b)  variable  definitions,  that  are  not  explicitly  imported  (see  Section  3.7). 

Any  occurrence  f  a  name  other  than  a  defining  occurrence  is  a  use  of  that  name.  A  use  of  a 
name  which  is  local  some  scope  must  correspond  to  a  definition  which  is  known  in  that  scope.  Each 
use  must  correspond  to  exactly  one  definition.  For  names  other  than  names  of  deferred  units,  at  most 
one  definition  of  a  name  will  be  knov/n  in  each  scope. 
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Definition*  which  are  exposed  in  a  acop*  (aea  Section  8.2)  ir*  considered  to  be  local  definitions  of  that  acopa. 

Uses  of  names  local  to  eomt  scop*  arc  uniformly  aasociated  with  definition*!  is.,  th*  definition  associated  with  a  particular  ua* 
it  th*  same,  no  matter  where  within  th*  scop*  that  us*  occur*. 

Conflicting  definitions  of  a  single  name  can  exist  in  different  acopes  without  restriction.  Conflicting  definitions  of  s  single 
name  within  s  single  scops  are  excluded  since  this  would  make  it  impossible  to  associate  each  us*  uniquely  to  a  single  definition. 

A  definition  may  be  any  of  th*  following:  a  declaration  (see  3.3),  a  formal  parameter  (see  7.3  ),  s  goto  label  (ss*  6),  the  index 
of  a  repeat  statement  (see  6.5),  a  matching  identifier  (see  6),  a  formal  parameter  (see  7.3),  a  generic  parameter  (see  1 1.3),  or  s 
needed  name  (see  1 1.4).  . 


EXAMPLES 


sample  BEGIN 

VAR  a,  b  :  INT<1. 
CONST  c  :=  4; 


X  definition  1 
.10);  X  definition  2  and  3 
X  definition  4 


BEGIN 

%  begin  statement  is  an  open  scope 
VAR  b  :  BOOL;  X  definition  5 


. .sample . 

*  *  3  *  e 

.  .b.. 

e  *  G  *  e 

*  *  P  *  # 

.  *x.  • 


X  refers  to  definition  1 
X  refers  to  definition  2 
X  refers  to  definition  5 
X  refers  to  definition  4 
X  refers  to  definition  6 
X  Illegal 


END; 

PROC  p  (VAR  x  ;  INT); 


X  definition  6  and  7 


X  procedure  is  a  closed  scope 


.sample. 

*  3  *  # 

.b.. 

.c. . 

.  p . . 

.X.  . 


X  illegal 
X  illegal 
X  illegal 

X  refers  to  definition  4 
X  refers  to  definition  6 
X  refers  to  definition  7 


END  PROC  p; 


END  sample; 
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3.6  FORWARD  REFERENCES  TO  NAMES 

Use  of  a  variable  or  constant  name  before  it  has  been  created  is  not  permitted. 
RULES 


No  use  of  a  name  defined  as  a  variable  or  constant  can  appear  before  its  definition. 

A  deferred  unit  is  said  to  require  a  variable  or  constant  if  it  either  contains  a  use  of  the  name  of 
the  variable  or  constant  or  contains  an  invocation  of  some  other  deferred  unit  that  requires  that 
variable  or  constant.  No  invocation  of  a  deferred  unit  that  requires  a  variable  or  constant  may  appear 
before  the  definition  of  that  variable  or  constant. 

NOTES 


Forward  references  to  deferred  definitions,  (oto  label*,  and  exception*  ar*  alway*  allowed. 

EXAMPLES 

1)  Legal  forward  reference  to  a  deferred  declaration. 

BEGIN 

p; 


PROC  pj 

END  PROC  p; 

END; 

2)  Correct  uses  and  incorrect  forward  references  to  immediate  declarations. 

VAR  a  :  INK  1..  10)  :=  b  +  3;  X  Incorrect,  b  Kgj  not  beep 

X  elaborated 


VAR  b  :  INTU..5)  :=  2; 
VAR  c  :  INTO.  .20)  :=  b; 


X  correct 

X  correct,  h  has  been  / 
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3.7  IMPORTS  LIST 


A  compound  declaration  (procedure,  function,  task,  or  capsule)  may  include  an  imports  list.  The 
imports  list  specifies  that  certain  variables,  known  in  the  enclosing  scope,  are  to  be  made  available  in 
the  compound  declaration.  A  variable  imported  into  a  compound  declaration  can  be  restricted  so  that 
It  cannot  be  modified  inside  the  compound  declaration. 

RULES 

•  # 

Every  name  in  the  imports  list  of  a  compound  declaration  must  be  associated  with  a  variable 

definition  (see  Section  4.2)  known  in  the  immediately  enclosing  scope. 

If  ALL  is  specified,  all  variable  definitions  which  are  known  in  the  enclosing  scope  are  available  to 
the  compound  declaration  (see  Section  3.5). 

If  a  list  of  names  is  specified,  the  definitions  associated  with  those  names  are  available  to  the 
compound  declaration. 

If  READONLY  precedes  a  name,  that  variable  is  treated  as  a  readonly  data  item  within  the 
compound  declaration  (see  Section  4.2). 
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NOTES 

Abbreviation  declarations  and  type  declarations  a ra  deferred  declarations  and,  Ihua,  a ra  cloaad  aeopaa.  Naithar  declaration  can 
inciuda  an  import  list  so  variables  from  ths  andoaing  tcopa  may  not  ba  usad  within  aithar  of  thaaa  dadaratiena. 

A  closad  scops  which  imports  ALL  is,  assantially,  an  opan  acopa  axcspt  that  goto  labals  and  matching  idantifiar*  ara  not 
availabla. 

EXAMPLES 

sample  BEGIN 

VAR  a.b  :  INT<0..10); 

CONST  c  :=  4; 

PROC  pi; 

%  known  =  c,  pi;  p 2,  p3 
END  PROC  pi; 

PROC  p 2  IMPORTS  a,  READONLY  b; 

%  known  =  a,  b(as  readonly),  c,  pi,  p2,  p3 

END  PROC  p2; 

PROC  p3  IMPORTS  ALL; 

%  known  =  a,  b,  c,  pi,  p2,  p3 

END* PROC  p3; 


END  sample; 
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4.  TYPES 

4.1  TYPES  AND  SUBTYPES 

Types  and  subtypes  are  used  to  specify  the  properties  of  data  Items.  These  properties  control 
both  the  values  that  a  data  item  may  have,  and  the  operators,  functions,  and  procedures  that  may  be 
applied  to  it. 

Data  properties  may  be  divided  into  two  groups:  type  properties,  which  must  be  known  during 
translation;  and  constraint  properties,  which  need  not  be  known  during  translation,  but  which  must  bo 
known  when  a  data  item  is  created.  The  type  of  a  data  item  is  the  collection  of  all  type  properties. 
The  subtype  of  a  data  item  is  the  collection  of  all  properties,  both  type  and  constraint  properties. 
The  subtype  of  a  data  item  is  said  to  belong  to  its  type.  Typically,  many  subtypes,  each  with  a 
different  set  of  constraint  values,  will  belong  to  the  same  type.  The  two  most  common  constraints  on 
types  are  range  constraints  (which  limit  the  range  of  values  of  data  Items  having  the  subtype >  and  size 
constraints  (which  specify  the  size  of  data  items  having  the  subtype >. 

EXAMPLES 
1>  Types 


INT 

FLOAT 

STRINGtASCII] 

2>  Subtypes 

INT( 1  ..10) 

FLOAT ( 5,  -100.0  ..  100.0) 

STRINGCASCII]  (5) 

4.1.1  USE  OF  TYPES  AND  SUBTYPES 

A  subtype  must  be  specified  wherever  a  data  item  is  to  be  created,  such  as  a  variable  declaration. 
A  type  or  a  subtype  must  be  specified  for  each  formal  parameter.  Invocation  of  a  deferred  unit  with 
formal  parameters  is  permitted  only  if  the  type  of  each  actual  parameter  is  the  same  as  the  type 
specified  (or  the  type  to  which  the  specified  subtype  belongs)  for  the  corresponding  formal  parameter. 
Verifying  that  types  are  the  same  is  called  type  checking;  since  types  consist  only  of  properties  that 
are  known  during  translation,  all  type  checking  is  done  during  translation  (see  Section  4.1.5). 
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EXAMPLES 

VAR  1  :  INTO..  10); 

VAR  s  :  STRING[ASCII3  (5); 

P(  1  > ; 

q(1 ); 

p(s);  %  Illegal  -  type  of  s  Is  not  INT 
PROC  p  (x  :  INT); 

END  PROC  p; 

PROC  q  (x  :  INK  1..  10)); 

END  PROC  q; 

4.1.2  SPECIFYING  TYPES  AND  SUBTYPES 

For  some  types,  the  only  type  property  is  their  name.  Examples  are: 

BOOL 

INT 

FLOAT 

Other  types  require  additional  properties.  These  properties,  for  all  types  but  arrays,  are  given  in  a 
comma-separated  list  enclosed  in  square  brackets,  called  the  type  property  list.  For  example, 

ENUMC'a,  'b,  * c 3  X  values  of  an  enumeration  type  are  always 

X  known  at  translation  time 

is  an  enumeration  type  for  the  values  'a,  ' b,  and  'c  . 

When  no  additional  constraints  are  needed  on  a  type  at  the  time  of  data  creation,  the  subtype 
specification  of  the  data  looks  the  same  as  the  type  specification  of  the  data.  For  example, 

BOOL 

ENUMC'a,  'b,  'c]  X  a  variable  of  this  subtypo  may  take  all  listed 

X  values 

When  additional  constraints  are  needed,  they  are  specified  in  a  comma-separated  list  enclosed  in 
parentheses,  called  the  constraint  property  list.  For  example, 

INK0..10)  X  a  single  range  constraint 

FLOAK10,  0.0  ..  50.0)  X  2  constraints,  precision  and  range 

ENUMC'a,  'b,  'c]  ('a  ..  ' b )  X  a  variable  of  this  subtype  may  only 

X  take  on  the  constrained  range  of 
X  values 
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In  some  cases,  the  properties  of  a  type  may  themselves  include  types.  For  example, 
RECORD C a  :  INT,  b  :  BOOL] 

STRINGtENUMt'a,  'b,  •  c] 3  X  the  characters  of  which  a  STRING  Is 

X  composed  must  be  known  at 
X  translation  time 


This  nesting  allows  types  to  be  constructed  based  upon  other  types.  For  example, 

RECORDta  :  INT, 

b  :  UNIONtw  :  BOOL, 

x,y  :  REC0RD[m,n  :  FLOAT], 
z  :  ENUMC’red,  'green]], 
c  *.  ENUMt'yes,  'no,  'maybe]] 


Subtype  constraints  are  specified  by  placing  constraint  property  lists  after  the  type  and  any  types 
contained  within  the  type.  For  example, 


RECORDta  :  INT(-5..5),  b  :  BOOL] 

STRINGtENUMt'a,  'b,  'c]  ('a  ..  'b>]  (10)  X  this  Is  a  string 

X  of  length  10  made  up 
X  only  of  A's  and  B's 


Array  types  and  array  subtypes  are  written  in  a  special  form.  For  example, 


ARRAY  INT  OF  FLOAT 
ARRAY  INT,  ENUMt'a,  'b,  'c] 

OF  FLOAT 


ARRAY  INK  1..  10)  OF 

FLOAK10,  -5.0  ..5.0) 

ARRAY  INK  1.  .10),  ENUMt'a,  'b,  'c] 
OF  FLOAK10,  -5.0  ..  5.0) 


X  a  one-dimensional  array  type. 
X  a  two-dimensional  array  type 
X  where  the  first  dimension 
X  is  subscripted  by  Integers 
X  and  the  second  by  enum 
X  literals. 

X  a  one-dimensional  array 
X  subtype. 

X  a  two-dimensional  array 
X  subtype  where  the  first 
X  dimension  has  size  10  and 
X  is  indexed  by  Integers 
X  and  the  second  has  size  3 
X  and  Is  Indexed  by  enum 
X  literals  (e.g,  x(5,  * b ) ) 


RULES 


When  a  specification  which  could  be  either  a  type  or  a  subtype  (e.g.,  BOOL  or  ENUMt'a,  ' b 3 )  is 
used  in  a  context  where  either  a  type  or  a  subtype  is  permitted  (e.g.,  for  a  formal  parameter),  the 
specification  is  interpreted  as  a  type. 
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EXAMPLES 

VAR  x  :  ENUMC'a,  'bl;  X  ENUMC'a,  *b3  is  a  subtype 

PROC  p<x  :  ENUMPa,  *b3 ) ;  X  ENUMC'a,  'b]  Is  a  type 

END  PROC  p; 

PROC  q(y  :  STRINGCENUMC 'a,  'b33  (5));X  ENUMC'a,  'b3  is  a  subtype 
END  PROC  q; 

4.1.3  RELATIONSHIP  BETWEEN  TYPES  AND  SUBTYPES 

Given  a  subtype ,  the  type  to  which  it  belongs  can  be  found  by  deleting  all  constraint  property  lists. 
For  example, 


Subtype 

BOOL 

INT<0. .10) 

ENUMC'a,  'b,  'c3  Pa  ..  'b> 
RECORDCa  :  INT(-5  ..  5), 
b  :  BOOL] 

STRINGCENUMC 'a,  'b,  'c] 

Pa  ..  'b>3  (10) 
ARRAY  INK  1..  10), 

ENUMC'a,  'b,  'e] 

OF  FLOATQ0, 0.0.  .100.0) 


lYfie 

BOOL 

INT 

ENUMC'a,  'b,  'c] 

RECORDCa  :  INT, 
b  ;  BOOL] 

STRINGCENUMC 'a,  'b,  *c] ] 

ARRAY  INT, 

ENUMC'a,  'b,  'c] 

OF  FLOAT 


4.1.4  LANGUAGE-DEFINED  AND  USER-DEFINED  TYPES 


The  language  defines  a  flexible  and  useful  set  of  types.  These  types  are  summarized  in  Section 
4.3.  Detailed  rules  are  given  in  Appendix  C. 

In  some  cases,  type  and  subtype  specifications  will  be  quite  long.  For  this  reason,  a  convenient 
abbreviation  facility  is  provided  (see  Section  4.4.1).  Users  can  also  define  the  abstract  types  which 
are  specifically  needed  for  their  applications.  This  capability  is  provided  by  the  type  declaration  (see 
Section  4.4.2)  together  with  the  capsule  declaration  (see  Chapter  8). 


abbreviation  invocation 
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Type  equivalence  rules  are  used  to  determine  if  two  types  are  the  same.  Type  checking  is  the 
comparison  of  two  types  using  the  type  equivalence  rules.  Types  are  checked  implicitly  for 
assignment  (see  Section  6.1)  and  for  invocation  of  deferred  units  (see  Section  3.3).  Types  are  checked 
explicitly  for  type  comparisons.  All  type  checking  occurs  at  translation  time. 

RULES 

Types 

Identifier  l  must  be  the  name  of  a  built-in  type.  The  abbreviation  invocation  must  produce  a  type. 
Identifier  3  must  be  associated  with  a  generic  parameter  that  has  a  type  generic  constraint  (see 
Section  11, .3.1). 

Type  Comparison 

The  result  of  elaborating  a  type  comparison  is  a  boolean  which  is  true  if  type  5  is  the  same  as 
type  6. 

To  determine  if  two  types  are  the  same,  the  types  are  first  expanded  and  then  compared. 

A  type  is  expanded  in  the  following  cases: 

a)  If  the  type  contains  any  abbreviation  invocations  (see  Section  4.4.1),  each  abbreviation 
invocation  is  replaced  by  the  type  which  is  the  result  of  the  invocation. 

b)  For  record  or  union  types,  any  components  of  the  form 

compl,  comp2,  compl  :  type 

are  replaced  by 

compl  :  type, 
comp2  :  type, 

compl  :  type 

c)  Any  TYPEOF  forms  are  replaced  by  their  result  type  (see  Section  4.5.2). 

d)  Any  references  to  type  generic  parameters  are  replaced  by  their  replacement  elements  (see 
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Section  11.3.1). 

Two  expanded  types  are  the  same  if  they  meet  the  following  requirements  when  compared: 
a>  corresponding  type  identifiers  within  the  expanded  types  refer  to  the  same  definition; 
b>  the  values  of  corresponding  properties  in  type  property  lists  are  the  same; 
c)  for  ARRAY  types,  the  corresponding  index  and  component  types  are  the  same;  and 
d>  for  RECORD,  and  UNION  types,  the  component  names  are  the  same  and  occur  in  the  same  order. 

NOTES 


Built-in  types  are  deecribed  in  Section  4.3  TYPEOF  it  deeertoed  in  Section  4.5.2. 

Type  checking  ie  simplified  by  the  feci  the!  ell  indirect  lypee  ere  new  lypet  end,  thue,  not  expended  into  their  underlying 
types.  This  meant  that  type  expansion  doe*  not  result  in  cycle*. 

EXAMPLES 

1)  Expanding  abbreviations 

ABBREV  a  :  BOOL; 

TYPE  b  :  BOOL; 


VAR  m  :  a; 

VAR  n  :  b; 

VAR  o  :  BOOL;  X  the  types  of  m  and  o  are  the  same  but  both 
X  are  different  from  the  type  of  n 

2>  Expanding  components 

VAR  a  :  RECOROtx.y  :  INT(1.. 10)]; 

VAR  b  :  RECORDtx  :  INT<5..8>, 

y  :  INT (12.  .15)];  X  the  types  of  a  and  b  are 

X  the  same  since  round 
X  bracketed  information 
X  is  removed  to  obtain 
X  the  type. 

VAR  c  :  RECORDty.x  :  INTU..10)];  X  the  type  of  c  is  not  the 

X  same  as  the  type  of  a, 

X  since  component  names 
X  are  in  a  different 
X  order. 


INI  tKMfc  I  K1U5  inu. 


oecuon  m.i.o 
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Subtype  equivalence  rules  are  used  to  determine  if  two  subtypes  are  the  same.  Two  subtypes  can 
be  explicitly  compared  for  equality  using  a  subtype  comparison. 

RULES 


Subtypes 


Identifier  1  must  be  the  name  of  a  built-in  type.  Abbreviation  invocation  1  must  produce  a  UNION 
subtype  with  no  subtype  constraint.  Abbreviation  invocation  2  must  produce  a  subtype.  Identifier  4 
must  be  associated  with  a  generic  parameter  that  has  a  subtype  generic  constraint  (see  11.3.2). 

Subtype  Comparison 

The  result  of  elaborating  a  subtype  comparison  is  a  boolean  which  is  true  if  subtype  6  is  the  same 
as  subtype  7. 

Two  subtypes  are  the  same  if  their  types  are  the  same  and  If  the  values  of  the  corresponding 
constraints  in  the  constraint  property  lists  are  equal.  Subtype  comparison  Is  only  permitted  for 
subtypes  whose  constraints  have  types  for  which  =  is  defined. 

NOTES 

Built-in  typaa  ara  daseribad  in  Section  4.3.  SUBTYPEOF  «nd  INDEXOF  ara  daserfoad  m  Section  4.5.1. 

Subtypes  are  eompsrad  for  equality  it  tranmlation  tuna  whanavtr  poaaibla,  otharwisa,  comparison  will  bs  parformad  at  runtlma. 

Two  subtypes  ara  implicitly  compared  for  equality  whan  an  tciut)  pirmeter  is  compared  to  a  forme)  ptrtmeter,  a  pacified  by 
tubtype,  and  bound  by  VAR  or  READONLY  (aaa  Saetion  7.3).  If  tha  compariaon  producaa  tha  valua  falaa  durinf  implicit 
compariaona,  tha  XJSUBTYPE  aaeaption  ia  rsiaad. 
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4.1.7  RANGE 


A  range  represents  a  contiguous  sequence  of  values  of  some  type. 

RULES 

Expression  1  and  expression  2  must  have  the  same  type. 

If  expression  i  is  less  than  expression  2,  the  range  represents  ail  successive  values  beginning  with 

the  lowest  value  < expression  l )  and  ending  with  the  highest  value  < expression  2).  If  expression  i  and 

expression  2  have  the  same  value,  the  range  represents  only  that  value.  If  expression  2  is  less  than 

expression  1 ,  the  range  represents  no  values. 

• 

NOTES 


Ranges  with  no  vtluot  trt  uttful  whon  dafininf  index  varitblat  (too  Section  6.5),  tinea  they  tllow  zero  altborttiona  of  a 
rapaat  statement  body,  tnd  whtn  dafininf  trrtyt  (it*  Stction  4.3,  Appandix  C.7),  tinea  they  tllow  empty  trrtyt.  Ranges  art  utod 
for  constraint  properties  of  integer,  enumerition,  tnd  floating  point  tubtypet,  for  case  statement  value  Itbalt  (to#  Sactlon  8.4),  and 
for  dicing  <t*e  Saction  5.3). 

EXAMPLES 

VAR  w  :  ENUMC  'one,  'two,  'three,  'four,  'five, 

'six,  'seven,  'eight,  'nine,  ’ten]  Cone  ..  'five); 

VAR  x,y  :  INT(1. .10)  :=  •  10 ; 

VAR  z  :  FLOAT( 10,1.0  ..  100.0); 

VAR  a  :  ARRAY  INT<l..x)  OF  BOOL; 

FOR  1  :  INT(x..y)  REPEAT 

END  REPEAT; 

CASE  x 

WHEN  1..  5  =>  ... 

WHEN  6.. 10  =>  ... 

END  CASE; 


. . ,a(x, ,y ) . . . 


4.2  VARIABLES  AND  CONSTANTS 


Each  variable  or  constant  has  a  subtype  which  is  known  when  it  is  created  and  does  not  change 
during  its  lifetime.  There  are  two  kinds  of  variables,  defined  variables  and  dynamic  variables.  The 
value  of  a  variable  may  be  both  accessed  and  modified.  The  value  of  a  constant  may  be  accessed  but 
not  directly  modified.  At  creation,  all  constants  must  be  initialized  to  some  value  and  each  variable  Is 
either  initialized  to  some  value  or  is  uninitialized.  Variables  and  constants  are  data  items  are  further 
described  in  Section  5.1. 

NOTES 

Defined  variables  are  apecified  in  the  followinj  way*: 

a)  a  variable  declaration  (declared  variable)  (tee  Section  4.2.1) 

b)  an  OUT  formal  parameter  (parameter  variable)  (*ee  Section  7.3) 
e)  a  VAR  formal  parameter  (parameter  variable)  (aee  Section  7,3) 

d)  a  repeat  statement  with  a  for  phraae  (index  veriable)  (tee  Section  8.5) 

Definition*  of  declared  variable*,  OUT  parameter  variable*,  and  index  variable*  create  new  variable*.  Definition*  of  VAR  parameter 
variable*  associate  new  names  with  exittin|  variables. 

There  are  alao  dynamic  variable*  which  are  not  defined  but  rather  eroatad  by  elaboration  of  the  ALLOC  atatament  (aee  Section 
4.4.3) 

Constants  are  defined  in  the  followinf  way*: 

a)  a  constant  declaration  (declared  constant)  (aee  Section  4.2.1) 

b)  a  CONST  formal  parameter  (parameter  constant)  (see  Section  7.2) 

Definition*  of  declared  constants  and  parameter  constants  create  new  constants. 
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4.2.1  VARIABLE  OR  CONSTANT  DECLARATION 


variable 

declaration 


£ 


These  declarations  define  variables  and  constants. 


RULES 

Each  identifier  is  defined  as  a  variable  (VAR  declaration)  or  a  constant  (CONST  declaration)  in  the 
scope  in  which  the  declaration  is  local. 

If  no  subtype  is  specified  for  a  constant,  the  subtype  of  the  constant  becomes  the  subtype  of  the 
initialization  expression.  Initialization  is  performed  by  assignment  ( ;s  ). 

Elaboration  of  a  variable  declaration  results  in  the  creation  of  a  variable.  If  an  initialization  phrase 
is  present,  the  variable  is  initialized  to  the  value  given  by  elaborating  the  expression  in  the 
initialization  phrase.  Elaboration  of  a  constant  declaration  results  in  the  creation  and  initialization  of  a 
constant. 


NOTES 


Wh*n  initialization  it  tptcifitd,  th#  type  of  tht  variable  or  constant  mutt  bt  tttifntbl*  (tea  Section  4.3).  The  XJNIT  •xeeption 
it  raitad  whan  tharo  it  «n  ttlampt  to  tccatt  tht  vtlut  of  an  uninitialized  vtriablt. 

Some  variables  art  tutomitietlly  initialized,  tvtn  >,  htn  initiatization  it  not  explicitly  tpteifitd.  Thatt  »ra  variables  of  indirect 
typta  and  ACT,  MAILBOX,  OATA  j.'0CK,  tnd  FILE  typei.  Automatic  initialization  etn  alto  be  ettabliahed  for  uter-deflned  typet  (ate 
Section  13.3). 

Location  specifications  are  uted  for  machine-dependant  rtpretentttioni  and  are  detcrfced  in  Section  12.3. 


EXAMPLES 

VAR  x  :  INK  1 . .  100)  :=  5; 

CONST  y  :=  TRUE; 

CONST  z  ■:  INT(0.  .10)  :=  10; 

VAR  a  :  FLOATU0.1.0  ..  1E3.0); 

4.3  OVERVIEW  OF  BUILT-IN  TYPES 

This  section  gives  a  brief  overview  of  the  types  which  are  built  into  the  language,  along  with  their 

subtypes,  procedures,  and  functions.  A  more  detailed  presentation  of  each  of  the  types  Is  given  in 

« 

Appendix  C. 

If  a  value  can  be  assigned  to  a  variable  (i.e.,  if  the  :=  procedure  is  defined),  the  type  of  the 
variable  is  said  to  be  assignable.  Note  that  assignment  is  used  in  the  following  cases: 

a)  assignment  statements  (see  Section  6.1); 

b)  initialization  (see  Section  4.2.1); 

c>  CONST  formal  parameters  (see  Section  7.3);  and 
d>  OUT  formal  parameters  (see  Section  7.3). 

The  relational  operators  are  =,  /=,  <,  >,  <=,  >=  (see  Section  5.2). 

Boolean 


Type:  BOOL 

Subtype:  BOOL 
Unary:  NOT 

Binary:  AND,  OR,  XQR,  =,  /= 

Assignable:  yes 
Literals:  see  Section  2.3.9 

Integer 

Type:  INT 

Subtype:  INT(m1n. .max) 

Unary:  +,  - 

Binary:  +,  -,  *,  DIV,  **,  MOD,  relational  operators 
Function:  ABS,  SUCC,  PRED 
Assignable:  yes 
Literals:  see  Section  2.3.6 
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Floating  Point 

Type:  FLOAT 

Subtype:  FL0AT(proc1s1on,  min.. max) 

Unary:  +  ,  - 

Binary:  +,  *,  /,  **,  relational  operators 

Function:  ABS,  FLOOR 
Assignable:  yes 
Literals:  see  Section  2.3.6 

Precision  is  the  minimum  number  of  decimal  digits  to  be  represented. 
Enumeration 


Type:  ENUM[enum-l  1  teral  1 ,  enum-1 1teral2 . enum-1  Itera In] 

Subtype:  ENUMC enum-1 1 teral 1 , enum-1 1 teral 2, . . . ,enum-11teraln] 

or 

ENUMC enum-1 1  teral  1, enum-1  Itera  12, . . enum-1 Itera In] (min .  .max) 

Binary:  relational  operators,  & 

Function:  5UCC,  PRED,  POS 
Assignable:  yes 
Literals:  see  Section  2.3.7 

Enumeration  values  are  ordered  as  they  appear  in  the  type  property  list,  with  the  leftmost 
being  lowest.  A  range  constraint  in  an  enumeration  subtype  restricts  values  from  the  set  of  all 
possible  values  (in  the  type)  to  the  set  of  legal  values  for  this  subtype. 

Record 


Type:  RECORD C comp  1 : type  1  ,comp2:type2, ... ,compn:typen] 

•  Subtype:  RECOROC comp  1 :  subtype  1,  comp2  rsubtypeZ, . . .  ,compn  :subtypen] 
Binary:  =,  /= 

Component  Selection:  record_var .comp 
Assignable:  yes,  if  all  components  are  assignable 
Constructor:  see  Section  5.6 

Successive  components  having  the  same  type  can  also  be  written  as 


comp  l,  comp2, . . . ,  compti :  type  j 


Union 


Type:  UNIONtcompl : typel,  comp2:type2 . compn:typen] 

Subtype:  UNIONtcompl : subtype  1 ,  comp2:subtype2, . . . ,compn :subtypen] 

or 

UNIONtcompl :subtypel,  comp2:subtype2, . . . ,compn:subtypen] 

(exp) 

Binary:  =,  /= 

Component  Selection:  unton_var .comp 
Tag  Inquiry:  unton_var .TAG 
Assignable:  yes,  if  all  components  are  assignable 
Constructor:  see  Section  5.6 

A  union  type  consists  of  multiple  components,  only  one  of  which  may  be  accessed  at  any 
point  in  the  lifetime  of  a  union  variable  of  this  type.  If  a  subtype  constraint  is  present, 
variables  with  that  subtype  can  have  only  the  component  whose  name  is  specified  in  the 
subtype  constraint  as  an  enumeration  value.  For  example, 

UNIONta  :  INT(0..10),  b  :  BOOL]  Cb); 

The  tag  inquiry  returns  the  name  (as  an  enumeration  value)  of  the  component  currently 
accessible.  The  component  which  is  present  in  a  union  may  change  over  the  lifetime  of  the 
union  variable.  Successive  union  components  having  the  same  type  can  also  be  written  as 

comp  1 , comp2 .... compn : type j . 

Array 

Type:  ARRAY  dim-typel,  d1m-type2, . . . ,d1m-typen  OF  comp-type 

Subtype:  ARRAY  dlm-subtypel ,  dim-subtype2, . . .dim-subtypen  OF  comp-subtype 
Binary:  &  (concatenation  for  one-dimensional  array),  a,  /a 
Component  Selection:  array_var(postttonl,  pos1tion2, . . .  ,posit1onn) 
array_var(m1n .  .max)  (slicing  for  one-dimensional 
array) 

Assignable:  yes,  if  component  type  is  assignable 
Constructor:  see  Section  5.6 

The  dimensions  must  be  integer  or  enumeration  types  or  subtypes. 


Set 


Type:  SET[type] 

Subtype:  SETfsubtype] 

Unary:  NOT  (complement) 

Binary:  AND  (intersection),  OR  (union), 

XOR  (symmetric  difference),  IN  (membership), 
relational  operations  (subset  relations) 

Assignable:  yes 
Constructor:  see  Section  5.6 

The  type  contained  in  the  type  property  list  can  only  be  INT  or  an  enumeration  type. 
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Type:  STRINGt type] 

Subtype:  STRINGfsubtype]  (length) 

Binary:  &  (concatenation),  relational  operations 
Component  Selection:'  str1ng_var(pos1tton) 
str tng_var<min . .max) 

Assignable:  yes 
Literals:  see'  Section  2.3.8 

The  type  contained  in  the  type  property  list  must  be  an  enumeration  type. 

Fixed  Point 

The  first  quarterly  review  of  the  DoD  common  language  effort  has  emphasized  the  lack  of  a 
consensus  on  the  military's  requirement  for  a  fixed  point  facility.  The  fixed  point  described  in 
Steelman  is  actually  a  scaled  integer  facility.  It  seems  that  more  discussion  is  necessary  before  a 
decision  is  reached  by  the  military  on  the  fixed  point  facility  necessary  for  most  applications.  When 
this  determination  is  reached,  the  design  can  be  built  into  this  language.  Some  of  the  possible  design 
alternatives  for  fixed  point  are  discussed  in  the  companion  Justification  document. 

NOTES 


Th*r»  »re,  bnnid**  IH*  b»sie  types  discusitd  »bov*,  som*  oth*r  built-in  typ*»  d*ti(;i*d  for  *p*ei*l  purpotot.  Th*  MAILBOX, 
DATA_LOCK,  «nd  ACT  typo*  »r*  dttcrlbod  in  ChipUr  18.  Th*  LATCH  typ*  i*  d**crib*d  in  Apptndix  C.13.  FILE  typ*«  *r*  d*acrib*d 
In  Appsndix  C.14.  PoinUr*  ar*  not  a  lan|ua|«  typ*  but  ar*  inataad  provid*d  vi*  th*  indirect  form  of  th*  type  decterutton  (••• 
Section  4.4.3). 


4.4  DECLARATION  OF  SUBTYPES  AND  TYPES 

Two  kinds  of  declarations  can  be  used  for  subtypes  and  types,  the  abbreviation  declaration  and  the 
type  declaration.  Both  are  deferred  declarations. 

An  abbreviation  declaration  defines  an  abbreviation.  Invocation  of  an  abbreviation  produces  the 
type  or  subtype  specified  in  the  declaration  of  the  abbreviation.  An  abbreviation  is  particularly  useful 
when  a  type  or  subtype  with  a  long  specification  is  needed  in  several  places  in  a  program.  As  with  all 
deferred  units,  an  abbreviation  can  be  parameterized.  This  permits  a  single  abbreviation  to  be  used 
to  abbreviate  a  set  of  related  subtypes. 

A  type  declaration  defines  a  new  type  distinct  from  all  other  types.  The  user  can  create  an 
abstract  data  type  by  placing  the  type  declaration  within  a  capsule  declaration,  together  with  a  set  of 
procedures  and  functions  which  operate  on  actual  parameters  of  the  defined  type.  Since  a  type  is  a 
deferred  unit,  it  may  be  parameterized  (parameters  are  used  to  specify  the  constraint  property  list  of 
subtypes  of  the  new  type)  and  may  be  generic  (the  translation  time  property  list  serves  as  the  type 
property  list).  There  are  two  basic  forms  of  the  type  declaration :  a  direct  type  declaration  and  an 
indirect  type  declaration.  Variables  and  constants  having  an  indirect  type  can  be  used  to  reference 
dynamically  allocated  variables. 


iiiTcniwic  i  muo  jmw. 
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4.4.1  ABBREVIATION 


Hir=: 
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The  identifier  in  an  abbreviation  declaration  is  defined  to  be  an  abbreviation  in  the  scope  in  which 
its  declaration  appears. 

Only  CONST  formal  parameters  may  be  used  in  an  abbreviation  declaration.  An  abbreviation 
declaration  which  abbreviates  a  type  may  not  have  any  formal  parameters. 

Elaboration  of  an  abbreviation  invocation  consists  of  elaborating  the  actual  parameters ,  binding 
the  actual  parameters  to  the  formal  parameters  of  the  named  subtype  abbreviation  (see  Section  7.3), 
and  elaborating  the  type  or  subtype  in  the  abbreviation  declaration.  The  result  of  the  Invocation  is  the 
elaborated  type  or  subtype.  If  the  specification  following  the  :  could  be  a  type  or  a  subtype,  then  the 
result  of  an  invocation  can  be  used  as  either  a  type  or  a  subtype.  Abbreviations  are  assumed  to  be 
normal  (see  Section  7.2.1). 

NOTES 


An  abbreviation  declaration  it  a  closed  tcope  The  format  parameters  trt  defined  in  (hit  teope.  Since  tn  abbreviation  declaration 
cannot  Have  an  imports  liti,  no  variable  namea  may  be  uted  within  (he  subtype. 

The  only  legal  use  of  (he  abbreviation  it  in  an  abbreviation  Invocation.  If  the  abbreviation  it  parameterized,  the  identifier  may 
not  be  uted  without  parameters  as  a  type. 

Recursive  cycles  involving  only  abbreviations  are  illegal  since  the  resulting  specification  would  be  infinite. 

Abbreviations  can  be  overloaded  (esc  Section  1 1.2)  and  can  be  generic  (see  Section  1 1.3). 


EXAMPLES 

ABBREV  110  :  INK  1..  10);  X  This  Is  equivalent  to 
VAR  y  :  110;  X  VAR  y  ;  INTO..  10); 


ABBREV  f lags(n  :  INT)  : 

ARRAY  INT(l..n)  OF  BOOL;  X  This  Is  equivalent  to 
VAR  b  ;  f  lags(  10 ) ;  X  VAR  b  :  ARRAY  INK  1..  10)  OF  BOOL; 


ABBREV  ASCII  :  ENUMC _ ] ; 

VAR  x  :  ASCII; 

PROC  p( x  :  STRINGtASCIIJ) ; 

END  PROC  p; 


X  see  Appendix  C  for  a  complete 
X  definition 
X  ASCII  Is  a  subtype  here 
X  ASCII  Is  a  type  here 
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A  type  declaration  defines  a  new  type,  distinct  from  all  other  types.  For  example,  the  declaration 

TYPE  bitsfn  :  INT)  :  ARRAY  INT(l..n)  OF  BOOL; 
defines  a  new  type 
bits 

Since  the  type  declaration  is  a  deferred  declaration,  it  defines  a  deferred  unit  (a  type)  which  can  be 
invoked.  Invocation  of  a  type  produces  a  subtype  of  that  type.  For  example, 

bits(5> 

is  a  subtype  of  the  type  bits.  The  actual  parameter  list  forms  the  constraint  property  list  of  the 
subtype.  For  example,  for  the  subtype  bits<5>,  the  constraint  property  list  is  (5).  The  formal 
parameters  of  a  type  are  also  used  to  define  the  attributes  of  subtypes  of  that  type  (see  Section  4.5.3). 

Each  subtype  of  a  type  is  defined  in  terms  of  the  subtype  specified  in  the  type  declaration,  which  is 
called  the  underlying  subtype.  For  example,  the  underlying  subtype  of  bits(5)  is 

ARRAY  INT<1.. 5)  OF  BOOL 

Each  underlying  subtype  of  a  new  type  will  belong  to  a  type  called  the  underlying  type.  For  example, 
the  underlying  type  of  bits  is  ARRAY  !NT  OF  BOOL.  Each  variable  (or  constant )  of  some 
user-defined  subtype  has  a  component  variable  (or  constant)  called  the  underlying  variable  (or 
underlying  constant)  of  the  underlying  subtype.  The  standard  component  selector  .ALL  is  used  to 
access  the  underlying  variable  or  constant  explicitly. 

Several  operations  are  automatically  defined  for  each  new  type:  access  to  the  underlying  variable 
or  constant;  access  to  components  (if  any),  equality,  and  assignment.  No  other  operations  are 
automatically  defined  for  a  new  type.  The  essential  operation  on  which  all  other  operations  are  based 
is  .ALL  qualification.  Given  a  variable  (or  constant)  with  some  new  type,  .ALL  qualification  produces 
the  underlying  variable  (or  constant).  For  example,  given 

VAR  a  :  b1ts(5); 

then 

a. ALL 

is  the  underlying  variable  of  a  and  has  subtype  ARRAY  INTM..5)  OF  BOOL 

If  the  underlying  type  has  components  (e.g.,  is  an  array,  record  or  union),  then  a  component 
selector  operation  is  automatically  defined  for  the  new  type  in  terms  of  the  component  selector 
operation  of  the  underlying  type.  For  example, 

a(  1 ) 

can  be  written  instead  of 
a.ALLd  ) 

If  the  underlying  type  is  assignable,  then  assignment  is  also  defined  for  the  new  type  in  terms  of 
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the  assignment  for  the  underlying  type.  For  example,  given 
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VAR  b,c  :  b1ts<5) ; 

then 

b  :  =  c ; 

can  be  written  instead  of 

b.ALL  :=  c.ALL; 

If  equality  is  defined  for  the  underlying  type,  then  equality  is  also  defined  for  the  new  type  In  terms 
of  equality  for  the  underlying  type.  For  example, 
b  =  c 

can  be  written  instead  of 
b.ALL  s  c.ALL 

A  new  abstract  type  can  be  created  by  placing  a  type  declaration  in  the  body  of  a  capsule. 
Operations  for  the  new  abstract  type  are  user-defined  by  procedures  and  functions  defined  in  the 
same  capsule.  The  operations  take  parameters  and/or  produce  results  of  the  abstract  typo.  These 
operations  are  implemented  using  .ALL  or  component  selection  to  access  the  underlying  variables  and 
constants.  One  important  property  of  an  abstract  data  type  is  that  it  is  possible  to  change  the 
underlying  type  without  affecting  any  users  of  the  abstract  type.  To  achieve  this,  users  of  the 
abstract  type  must  be  denied  access  to  the  underlying  variables  of  the  abstract  type.  This  is 
accomplished  by  not  exporting  either  .ALL  qualification  or  any  of  the  selector  operations  that  are 
automatically  defined. 

RULES 

The  identifier  in  a  direct  type  declaration  is  defined  to  be  a  type  name  in  the  scope  in  which  the 
type  declaration  appears.  If  there  is  no  formal  translation  time  property  list,  then  this  identifier  is  the 
type.  If  there  is  a  formal  translation  time  property  list,  then  the  types  consist  of  the  type  identifier 
together  with  an  actual  translation  time  property  list. 

Only  CONST  formal  parameters  may  be  used  in  a  type  declaration. 

Elaboration  of  a  user-defined  subtype  consists  of  elaborating  the  actual  parameters,  binding  the 
actual  parameters  to  the  formal  parameters  of  the  named  type  (see  Section  7.3>,  and  elaborating  the 
subtype.  The  result  of  a  user-defined  subtype  is  a  subtype  of  the  invoked  type,  whose  constraint 
property  list  is  the  actual  parameter  list  of  the  invocation.  The  underlying  subtype  of  this  result 
subtype  is  the  elaborated  subtype. 

Each  newly  defined  type  has  the  following  operations  automatically  defined: 

a>  Assignment  ( :  =  )  is  defined  in  terms  of  assignment  for  the  underlying  type.  If  the  underlying 
type  is  not  assignable,  the  defined  type  is  not  assignable. 

b>  Equality  <=)  is  defined  In  terms  of  equality  for  the  underlying  type.  If  equality  is  not  available 
for  the  underlying  type  then  it  is  not  available  for  the  defined  type. 
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c)  Component  selection,  if  the  underlying  type  has  components. 

d)  .ALL  qualification,  which  allows  access  to  underlying  variables  and  constants. 

Types  are  assumed  to  be  normal  (see  Section  7.2.1). 

NOTES 

A  new  type  it  invoktd  to  product  «  subtype  of  (hit  new  type.  Unliko  en  abbreviation,  if  the  type  it  parameterized  (end  hit  no 
type  proptrty  litt),  the  identifier  mty  bt  utad  without  parameters  tt  «  type.  If  no  piramettr  liat  It  prtttnf  in  th»  type  declaration, 
the  dofined  typo  has  only  a  single  subtype  If  a  formal  parameter  liat  is  present,  the  defined  type  hat  one  or  more  subtypes. 

A  type  declaration  it  a  closod  scope  The  formal  parameter  names  tre  defined  in  this  teope.  Since  a  type  declsrstlon  cannot 
have  an  imports  list,  no  variable  names  may  be  used  within  the  subtype. 

Utart  can  define  their  own  assignment  ( •)  procedure,  equality  (•)  function,  end  selection  functiona  for  new  types.  A  uter 
definition  of  assignment,  equality,  or  of  selection  will  override  the  automatically  provided  assignment  (aee  Section  13),  equality  (tee 
Section  415),  or  selection  (aee  Section  13  4).  It  it  also  possible  to  define  initialization  and  finalization  oparatione  which  are 
automatically  'nvoked  at  the  beginning  and  end  (respectively)  of  the  lifetime  of  a  data  item  having  a  user-defined  type  (aee  Section 
13.3). 

The  type  declaration,  when  used  in  a  generic  declaration  (aee  Section  1 1.3),  can  be  used  to  create  a  family  of  types.  Any  actual 
translation  time  property  list  earvea  aa  the  type  properly  litt. 

Representation  specification*  are  used  for  machine-dependent  programs  and  are  described  in  Section  12.2. 
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1>  New  string  types 

TYPE  strngl0  :  STRINGCASCII]  (10); 

GENERIC  1  :  INT 

TYPE  mstrngCI]  :  STRINGCASCII]  (1); 

TYPE  strng  (J  :  INT)  :  STRINGCASCII]  (j>; 

VAR  x  :  strngl0;  X  underlying  variable  Is  a  string 

X  with  length  10 

VAR  y  :  mstrng  Ck3;  X  underlying  variable  is  a  string  with 

X  length  k  where  the  value  of  k  must 
X  be  known  at  translation  time 
VAR  z  :  strng  (m);  X  underlying  variable  is  a  string  with 

X  length  m  where  the  value  of  m  need 
X  not  be  known  until  run  time. 

2)  An  abstract  data  type  --  stacks 

CAPSULE  stackcap  EXPORTS  stack,  Inlt,  push,  pop; 

CONST  size  :=  100; 

ABBREV  elemtype  :  FLOAT(10,  -100S.0  ..  1000.0); 

TYPE  stack  :  RECORDt  top  :  INT(0 . .size) , 

elem  :  ARRAY  INK  1.. size)  OF 
elemtype] ; 


PROC  Inlt  (VAR  s  :  stack); 

s.top  :=  0; 

END  PROC  ini t; 

PROC  push  (VAR  s  :  stack,  e  telemtype); 
s.top  :=  s.top  +  1; 
s.elem(s.top)  :=  e; 

END  PROC  push; 

PROC  pop  (VAR  s  :  stack,  OUT  e  :  elemtype); 
e  :=  s.elem(s.top); 
s.top  :=  s.top  -  1; 

END  PROC  pop; 


END  CAPSULE  stackcap; 
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variable).  For  example.  In  5°™  <U-  "  **»•»'  <°  »»  dynamic 

TYPE  t  :  PTR  STRINGCASCin  (5): 

VAR  x,y  :  t; 

. . .  There  Is  IoVZ^Tvlee  *  . WW“«' 
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x  :=  NIL; 

sets  the  value  of  x  to  be  nil. 

A  dynamic  variable  is  created  by  elaboration  of  an  allocution  itatament.  For  example,  elaboration 
of 

ALLOC  y  PTR  :=  "ABCDE"; 

creates  a  new  dynamic  variable  with  subtype  STRINGtASCII]  (5),  initializes  it  to  have  the  value 
"ABCDE",  and  sets  y  to  point  to  this  dynamic  variable.  Note  that  dynamic  variables,  unlike  other 
variables,  are  not  defined  or  named. 

Dynamic  variables  are  referenced  via  indirect  variables.  As  with  direct  types,  .ALL  qualification 
and  component  selection  operations  (if  the  underlying  dynamic  variable  has  components)  are 
automatically  defined.  These  operations  are  permitted  only  if  the  value  of  the  Indirect  variable  Is  not 
nil.  The  operations  provide  access  to  the  referenced  dynamic  variable  or  Its  components  (i.e.,  they 
are  'dereferencing'  operations).  For  example, 

VAR  sl,s2  :  t; 

ALLOC  s2  PTR  :=  "value";  X  create  dynamic  variable 


...sl.ALL...  X  illegal  since  si  is  nil 

...sl(i)...  X  Illegal  since  si  is  nil 

.  ,.s2.ALL...  X  the  dynamic  variable  pointed  to 
X  by  s2,  having  the  value  "ABCDE" 

. . ,s2(3) . . .  X  a  component  of  the  dynamic 

X  variable  pointed  to  by  s2, 

X  having  the  value  'C 

«  «  • 

ALLOC  si  PTR;  X  create  dynamic  variable  2 

sl.ALL  :=  s2 .ALL;  X  sets  the  value  of  dynamic  variable  2 
X  to  be  equal  to  the  value  of  dynamic 
X  variable  1  ("value") 


The  lifelime  of  a  dynamic  variable  is  different  than  that  of  other  variables.  A  dynamic  variable 
exists  as  long  as  there  is  some  way  of  accessing  it.  This  means  that  the  lifetime  of  a  dynamic  variable 
Is  not  coupled  to  the  elaboration  of  a. scope. 

As  is  the  case  for  direct  types,  assignment  (:=)  is  also  automatically  defined  for  indirect  types. 
The  assignment  operation  for  indirects,  however,  is  a  "sharing”  assignment.  For  example, 

VAR  al,a2,bl,b2,b3  :  t; 

ALLOC  bl  PTR  :=  "WXYZ"  ;  X  creates  dynamic  variable  1 

ALLOC  b3  PTR  :=  "abode";  X  creates  dynamic  variable  2 

al  :=  NIL;  X  sets  al  to  nil 

a2  :=  al;  X  sets  a2  to  nil 

b2  :=  bl;  X  bZ  now  points  to  dynamic 

X  variable  1 

bl.ALL  :  =  b3.ALL;  X  changes  value  of  dynamic 

X  variable  1 

...  bl.ALL  ...  X  has  value  "abcde" 

...  bZ.ALL  ...  X  has  value  "abcde" 
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. ..  b3.ALL 


X  has  value  "abode" 


The  equality  operators  (=,  /=)  are  also  automatically  defined  for  indirect  types.  For  example, 


,  ,  .  3  }  —  3  2  .  •  • 

. . .bl  =  b2 . . . 

. . .b2  «  b3. . . 

. .  .b2 .ALL  =  b3 .ALL. . 


X  true,  both  are  nil 

X  true,  both  point  to  same  dynamic  variable 
X  false,  each  points  to  different 
X  dynamic  variable 

X  true,  both  dynamic  variables  have  the 
X  value  "abcde" 


As  is  the  case  for  all  data  items,  the  subtype  of  a  dynamic  variable  need  not  be  known  until  the 
dynamic  variable  is  created.  Constraints  on  a  dynamic  variable  which  are  to  be  resolved  at  creation 
time  are  specified  via  an  allocation  property  list  in  an  allocation  statement.  For  example, 

TYPE  vstring  :  PTRden  :  INT)  STRINGCASCII]  (len); 

VAR  vl,v2  :  vstring; 

ALLOC  vl  PTR(3)  :=  "abc";  X  (3)  is  the  allocation 

X  property  list 

ALLOC  v2  PTR(4 )  :=  "abed"; 

Dynamic  variables  can  contain  components  having  indirect  types  which  reference  other  dynamic 
variables.  This  means  that  recursive  data  structures  and  data  structures  having  cycles  can  be  created. 
For  example, 

TYPE  list  :  PTR  RECORDC  val  :  INT(0..100>, 

next  :  list]; 

VAR  1st  :  list; 

X  create  a  singly  linked  list  with  3  elements 

ALLOC  1st  PTR  :=  [val  :  3,  next  :  NIL]; 

ALLOC  1st  PTR  :=  [val  :  2,  next  :  1st]; 

ALLOC  1st  PTR  :=  [val  :  1,  next  :  1st]; 

X  now  make  the  list  circular 

1st. next. next. next  :=  1st; 

In  addition  to  indirect  variables,  it  is  also  possible  to  define  indirect  constants.  Like  all  constants, 
an  indirect  constant  must  be  initialized  and  its  value  may  not  be  changed.  The  value  of  the  dynamic 
variable  which  it  references  may,  however,  be  changed. 

When  creating  an  abstract  data  type  and  its  subtype,  the  programmer  must  ensure  that  the 
implementation  of  the  abstract  type  is  invisible  to  the  user.  This  permits  the  implementation  to  be 
changed  without  affecting  those  parts  of  a  program  which  use  the  abstract  type.  The  programmer 
who  implements  an  abstract  type  should  be  able  to  change  the  underlying  type  from  a  direct  type  to 
an  indirect  type  <and  vice  versa),  without  affecting  the  users  of  the  abstract  type.  For  example,  an 
abstract  stack  data  type  could  be  implemented  using  either  an  array  (a  direct  type)  or  a  linked  list 
(achieved  via  an  indirect  type).  For  this  reason,  it  is  important  that  when  a  type  is  exported  from  a 
capsule  used  to  realize  an  abstract  data  type,  it  should  not  be  possible  to  detect  outside  the  capsule 
whether  the  exported  type  was  a  direct  or  an  indirect  type. 
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As  mentioned  above,  a  dynamic  variable  exists  as  long  as  there  is  some  way  to  access  it. 
Detecting  when  there  is  no  longer  any  way  to  access  a  dynamic  variable  and  reclaiming  the  storage 
that  was  used  for  it  usually  involves  a  process  called  garbage  collection.  In  some  cases,  the  overhead 
of  full  garbage  collection  can  be  avoided  and  a  simpler  and  less  costly  strategy  used.  For  cases 
where  this  is  impossible,'  the  user  can  avoid  garbage  collection  costs  by  the  use  of  the  FREE 
procedure.  If  v  is  an  indirect  variable  that  points  to  some  dynamic  variable  and  there  are  no  other 
pointers  to  that  dynamic  variable,  then 

FREE(v) ; 

reclaims  the  storage  for  that  dynamic  variable  and  sets  the  value  of  v  to  nil.  If  there  were  other 
pointers  to  the  dynamic  variable,  the  X_FREE  exception  is  raised  (this  prevents  the  problem  of 
dangling  pointers).  Although  this  avoids  the  cost  of  garbage  collection,  it  Introduces  some  cost  in 
checking  that  there  are  no  other  pointers.  For  those  cases  where  even  this  cost  is  unacceptable,  it  is 
possible  to  inhibit  the  generation  of  code  for  doing  this  checking  by  suppressing  the  X_FREE 
exception  (see  Appendix  B>. 

RULES 


Indirect  Type  Declaration 

The  identifier  In  an  indirect  type  declaration  is  defined  to  be  a  type  name  In  the  scope  In  which 
the  indirect  type  declaration  appears.  Indirect  types  are  referenced  using  the  same  rules  (both 
syntax  and  semantics)  as  for  direct  types  (see  Section  4.4.2). 

Only  CONST  formal  parameters  may  be  used. 

Indirect  types  are  invoked  using  the  same  syntax  as  direct  types  (see  Section  4.4.2).  Elaboration 
of  a  user-defined  subtype  consists  of  elaborating  the  actual  parameters  and  binding  the  actual 
parameters  to  the  formal  parameters  1  of  the  named  type  (see  Section  7.3). 

The  result  of  a  user-defined  subtype  is  a  subtype  of  the  invoked  type,  whose  constraint  property 
list  is  the  actual  parameter  list  of  the  invocation. 

The  value  of  an  indirect  variable  or  constant  is  either  nil  or  a  reference  to  some  underlying 
dynamic  variable.  All  indirect  variables  are  automatically  initialized  to  have  the  value  nil. 

The  following  operations  are  automatically  defined  for  each  indirect  type: 

a)  Assignment  ( :.  )  is  a  sharing  assignment.  If  the  indirect  subtypes  of  left  hand  side  and  right 
hand  side  are  not  equal  the  X_SU£TYPE  exception  is  raised. 

b)  Equality  (=)  is  defined  to  produce  true  if  both  of  its  actual  parameters  are  nil  or  If  both 
reference  the  same  dynamic  variable. 

c)  Component  selection,  if  the  underlying  type  has  components.  If  the  value  of  the  variable  or 
constant  is  nil  when  component  selection  is  applied  to  the  variable  or  constant,  the  X_NIL 
exception  is  raised. 

d)  .ALL  qualification  which  gives  access  to  the  underlying  dynamic  variable.  If  the  value  of  the 
variable  or  constant  is  nil  when  .ALL  qualification  is  applied  to  the  variable  or  constant,  the 
X_NIL  exception  is  raised. 

Types  are  assumed  to  be  normal  (see  Section  7.2.1). 


Section  4.4.3 


RED  LRM  8  March  1979 


64 

Allocation  Statement 

The  variable  must  have  an  indirect  type  on  which  .ALL  qualification  is  available. 

Elaboration  of  the  allocation  statement  consists  of: 

a)  elaborating  the  variable; 

b)  elaborating  the  actual  parameters; 

c)  binding  the  actual  parameters  to  the  formal  parameters  2  in  the  indirect  type  declaration 
associated  with  the  type  of  the  variable; 

d)  elaborating  the  subtype  in  the  indirect  type  declaration; 

e)  allocating  a  dynamic  variable  having  that  subtype; 

f)  if  initialization  is  specified,  Initializing  the  newly  created  dynamic  variable  (using  :*>,  and 

g)  setting  the  variable  named  in  the  allocation  statement  to  be  a  reference  to  the  newly  created 
dynamic  variable. 

The  dynamic  variable  must  have  an  assignable  type  if  initialization  is  specified  In  an  allocation. 
statement. 

NOTES 


Bacauaa  indirect  typaa  ara  alwaya  naw  typac,  and  (hartfora  namad,  (ha  typa  aquivalartca  rulaa  ara  aimplifiad  (»•*  Section 
4.1.5). 

An  indirect  type  dedaritbn  ia  a  cloaad  teopa.  Tha  formal  paramatar  namaa  (of  both  formal  paramatar  lists)  ara  daflnad  In  this 
■cop*.  Since  a  type  declsrstbn  cannot  hava  an  importa  liat,  no  variabla  namat  may  bs  uaad  within  tha  subtype. 

Rapraaantation  apocificationa  ara  uaad  for  machirta-dapandani  proframa  and  ara  dauerfcad  in  Section  1Z.Z. 


EXAMPLES 

1)  Indirect  string  types 

TYPE  strl0  :  PTR  STRINGCASCII]  (10); 


GENERIC  1  :  INT 

TYPE  mstr  [1]  :  PTR  STRINGCASCII]  (1); 
TYPE  str(  j  :  INT)  ;  PTR  STRINGCASCII]  (J); 
TYPE  vstr  :  PTR(u  ;  INT)  STRINGCASCII]  (u); 


VAR  w  ;  strl0; 
VAR  x  ;  mstr  Cm3; 

VAR  y  :  str(n); 

VAR  z  :  vstr; 


X  w  can  point  only  to  strings 
X  of  length  10 
X  x  can  point  only  to  strings 
X  of  length  m  where  the  value  of 
X  m  must  be  known  at  translation 
X  time 

X  y  can  point  only  to  strings 
X  of  length  n  where  the  value  of 
X  n  need  not  be  determined  until 
%  run-time 

X  z  can  point  to  strings  of  any 
X  length.  The  length  of  the 
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X  string  Is  determined  when  the 
X  string  Is  allocated. 

2)  Defines  symbol  tables  which  can  hold  symbols  of  different  lengths 

CAPSULE  sym_tab_cap  EXPORTS  sym_tab,  inlt,  Insert,  1ook_up; 

.  TYPE  sym  :  PTR  den  :  INT)  STRINGtASClUden) ; 

TYPE  syra_tab  (size  :  INT)  :  RECORD [top  :  INK 0 .  .size) , 

syms  :  ARRAY 

INT(1. .size) 
OF  sym] ; 


PROC  inlt  (VAR  s  :  synutab); 

s.top  :*  0; 

ENO  PROC  Inlt; 

FUNC  1ook_up  (READONLY  s  :  sym_tab, 

val  :  STRINGtASCII) ) 

=>  INT(0. .s.top); 

FOR  1  :  INK  1  ..  s.top)  REPEAT 
IF  s.syms(1).ALL  *  val  THEN 
RETURN  1; 

END  IF; 

END  REPEAT; 

RETURN  0; 

END  FUNC  look_up; 

PROC  Insert  (VAR  s  :  sym_tab, 

val  :  STRINGtASCII] , 

OUT  Index  :  INT); 

Index  look_up  (s,  val); 

IF  1ndex=0  THEN 

s.top  ;*  s.top  +  1; 

ALLOC  s.syms(s.top)  PTP.  (val.LEH)  :»  val; 
Index  :s  s.top; 

END  IF; 

END  PROC  Insert; 


END  CAPSULE  sym_tab_cap; 
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4.5  TYPE  AND  SUBTYPE  INQUIRY,  PREDICATES  AND  ASSERTIONS 

Since  a  formal  parameter  can  specify  a  type,  rather  than  a  subtype,  a  deferred  unit  with  a  formal 
parameter  can  be  invoked  with  actual  parameters  having  any  subtype  belonging  to  that  type.  Although 
this  flexibility  is  often  quite  useful,  there  are  cases  where  it  is  desirable  to  further  limit  either  the 
values  or  subtypes  that  actual  parameters  are  permitted  to  have  (in  order  to  exclude  values  which  are 
not  meaningful  for  the  deferred  unit).  In  many  cases,  these  limitations  also  allow  the  translator  to 
produce  more  efficient  code. 

Some  limitations  can  be  achieved  by  specifying  a  subtype  (rather  than  a  type)  for  a  formal 
parameter.  A  finer  degree  of  control  can  be  achieved  by  including  an  assertion  at  the  beginning  of  the 
body  of  the  deferred  unit.  Assertions  concerning  subtypes  are  supported  by  language  facilities  for 
inquiring  about  the  type,  subtype  and  subtype  properties  of  a  data  item.  These  features  are  discussed 
in  the  following  subsections. 

Inquiry  is  also  useful  for  several  other  purposes,  including  specifying  the  subtype  of  local  data 
Items  of  a  procedure  or  function  and  accessing  array  index  bounds. 

4.5.1  SUBTYPE  INQUIRY 
RULES 

If  exp  is  any  expression,  then  the  result  of  elaborating 
SUBTYPEOF(exp) 
is  the  subtype  of  that  expression. 

If  exp  is  an  expression  for  an  n-dimensionai  array  and  i  is' a  manifest  integer  expression  whose 
value  is  between  one  and  n,  then  the  result  of  elaborating 

INDEXOF( exp,  1) 

is  the  I'th  index  subtype  of  the  array.  The  form 

INDEXOF(exp) 
is  equivalent  to 

INDEXOF(exp,  1) 


PROC  q  (VAR  a,b  ;  ARRAY  INT  OF  FLOAT); 
ASSERT  INDEXOF(a)  =  INDEXOF(b) ; 


]  END  PROC  q; 

i  FUNC  search  (a  :  ARRAY  INT  OF  FLOAT,  v  :  FLOAT)  »>  INDEXOF(a) ; 

FOR  1  :  INDEXOF(a)  REPEAT 

'  IF  a(1)  =  v  THEN 

}  RETURN  1 ; 

i  END  IF; 

END  REPEAT; 

,  RAISE  not_found; 

,  END  FUNC  search; 

!  PROC  r  (VAR  x,y  :  FLOAT); 

ASSERT  SUBTYPEOF(x)  =  SUBTYPEOF(y) ; 

END  PROC  r; 

4.5.2  TYPE  INQUIRY 
RULES 

If  exp  is  an  expression ,  then  the  result  of  elaborating 
TYPEOF(exp) 

is  the  type  of  that  expression.  If  st  is  a  subtype,  then  the  result  of  elaborating 
TYPEOF(st) 

is  the  type  to  which  that  subtype  belongs  (see  Section  4.1.3). 

NOTES 


Eftboririioni  of  TYPEOF  pie«*  durirn  (rantltiioa 
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4.5.3  ATTRIBUTES 

In  addition  to  inquiry  of  an  entire  subtype,  it  is  also  possible  to  inquire  about  specific  subtype 
constraints,  called  attributes. 

RULES 

The  attributes  of  built-in  types  are  listed  in  Appendix  C. 

Each  formal  parameter  of  a  user-defined  type  is  an  attribute  of  that  type.  The  identifier  which  Is 
the  name  of  the  formal  parameter  is  used  as  the  attribute  name. 

ATTRIBUTE  INQUIRY 


Attribute  inquiry  allows  attribute  values  to  be  accessed. 

RULES 

The  identifier  must  be  the  name  of  an  attribute  of  the  specified  subtype  or  of  the  subtype  of  the 
specified  expression. 


Elaboration  of  attribute  inquiry  produces  the  value  of  that  attribute. 
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INK  1 . .  10 )  .MAX  X  10 

FL0AK5,  0.0  . .  10 .0)  .PREC  X  5 
STRING [ASC 113(8) .  LEN  X  8 


TYPE  matrix  (first,  second  t  INT)  :  ARRAY  INT(1. .first), 

INT(1. .second) 

OF  FLOAK10,  -100.0  . .  100.0); 

matr1x(5,8).f1rst  X  5 

matr1x( 5,8) .second  X8 


PROC  s  (VAR  x  :  FLOAT); 
ASSERT  x.PREC  <=  10; 

END  PROC  s; 


FUNC  search  1  (a  :  ARRAY  INT  OF  FLOAT,  v  :  FLOAT) 
=  >  INK -1  ..  INOEXOF(a)  .MAX) ; 
ASSERT  INDEXOF(a) .MIN  =  0; 

FOR  1  :  INOEXOF(a)  REPEAT 
IF  a(1)  =  v  THEN 
RETURN  1; 

END  IF; 

END  REPEAT; 

RETURN  -1; 

END  FUNC  searchl ; 


PROC  sort  (VAR  a  :  ARRAY  INT  OF  STRINGCASCII) ) ; 
ABBREV  x  :  INDEXOF(a) ; 

FOR  1  :  INKx.MIN  ..  PRED(x.MAX))  REPEAT 

FOR  j  :  REVERSE  INT(1  ..  PRED(x.MAX))  REPEAT 
CONST  k  :=  J  +  1; 

IF  a( j)  <  a(k)  THEN 
CONST  t  :=  a( j) ; 
a(j)  :=  a(k); 
a(k)  :s  t; 

END  IF; 

END  REPEAT; 

END  REPEAT; 

END  PROC  sort; 
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5.  EXPRESSIONS 

5.1  DATA  ITEMS 

There  are  five  Kinds  of  data  items:  defined  variables,  dynamic  variables,  defined  constants, 
readonly  data  items,  and  temporary  data  items.  Defined  variables  and  constants  are  described  in 
Section  4.2.  Dynamic  variables  are  described  in  Section  4.4.3.  Readonly  and  temporary  data  items  are 
discussed  below. 

The  term  variable  is  used  to  refer  to  defined  and  dynamic  variables.  The  term  constant  Is  used  to 
refer  to  defined  constants,  readonly  data  items,  and  temporary  data  items. 

RULES 

A  data  item  can  hold  a  single  value.  The  value  of  any  data  item  may  be  accessed  <l.e.,  read).  The 
value  of  variables  <both  defined  and  dynamic)  and  their  components  may  also  be  modified.  The  value 
of  other  data  items  may  not  be  modified. 

A  readonly  data  items  is  a  variable  whose  use  is  restricted  in  certain  contexts.  Within  those 
contexts,  the  value  of  the  readonly  data  item  cannot  be  modified  directly.  In  some  cases,  however,  It 
Is  possible  for  the  value  of  the  readonly  data  item  to  be  modified  indirectly,  outside  the  context. 

a>  When  an  actual  parameter  variable  is  bound  to  a  READONLY  formal  parameter,  the  formal 
parameter  is  treated  as  a  readonly  data  item  within  a  deferred  declaration.  Changes  to  the 
actual  parameter  variable  will  change  the  formal  parameter  (see  Section  7.3).  This  is  the  only 
way  that  dynamic  variables  may  be  made  readonly. 

b>  Variables  imported  READONLY  into  a  compound  declaration  are  treated  as  readonly  data  items 
within  the  compound  declaration.  The  variable  may  be  changed  outside  the  compound 
declaration  (see  Section  3.7  ). 

c)  Variables  exported  READONLY  from  a  capsule  into  a  scope  where  the  capsule  is  invoked  are 
treated  as  readonly  data  items  within  that  scope.  The  variable  may  be  changed  within  the 
capsule  (see  Section  8.2) 

d>  Variables  exported  from  a  capsule  and  exposed  as  READONLY  are  treated  as  readonly  data  items 
within  the  scope  in  which  the  capsule  is  invoked.  The  variable  may  be  changed  within  the 
capsule  (see  Section  8.1). 

A  temporary  data  item  is  the  result  of  a  built-in  or  user-defined  literal  or  constructor  (see 
Sections  2.3.5,  5.6,  and  5.7),  the  result  of  a  function  or  operator  (see  Section  7.2),  or  the  result  of 
attribute  inquiry  (see  Section  4.5.3).  For  convenience,  these  results  will  be  referred  to  as  values. 

The  lifetime  of  all  defined  variables  and  constants  and  formal  parameters  (and  their  components)  is 
the  lifetime  of  the  scope  immediately  containing  their  definition.  The  lifetime  of  dynamic  variables 
extends  from  their  creation  by  the  allocation  statement  until  the  time  when  they  can  no  longer  be 
accessed.  The  lifetime  of  temporary  data  items  extends  from  the  time  they  are  produced  until  the  end 
of  the  elaboration  of  the  construct  in  which  the  temporary  is  used. 

Initialization  can  optionally  be  specified  whenever  a  variable  is  created.  For  some  types,  if  no 
initialization  is  specified,  there  is  a  default  initial  value.  Otherwise,  the  variable  is  uninitialized  until  a 
value  has  been  assigned  to  it.  An  attempt  to  access  the  value  of  an  uninitialized  variable  will  raise  the 
X_INIT  exception. 
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5.2  OPERATORS  AND  OPERANDS 


An  expression  is  a  computational  rule  for  producing  a  data  item.  An  expression  can  be  a  single 
operand  or  a  combination  of  operators  and  operands.  Operators  are  either  prefix  or  infix  operators. 
Prefix  operators  immediately  precede  an  operand.  Infix  operators  operate  upon  a  left  and  right 
operand  to  produce  a  value.  The  association  of  operands  to  an  operator  is  determined  by  the 
precedence  of  operators.  Operands  are  associated  with  the  operator  of  higher  precedence. 

Parentheses  can  be  used  to  modify  the  association  (see  Section  5.3). 

RULES 

Operator  symbol  I  is  a  prefix  operator.  Valid  prefix  operator  symbols  are  +,  and  NOT. 
Operator  symbol  2  is  an  infix  operator.  Valid  infix  operator  symbols  are  *$,  *,  /,  MOD,  DIV,  &,  +,  -,  s, 
/a,  <,  <=,  >,  >=,  IN,  AND,  OR,  and  XOR.  . 


The  operands  of  prefix  and  Infix  operators  are  determined  based  on  the  built-in  precedence  of 
operators  given  below: 


highest  precedence 

+,  -  (prefix) 

** 

*,  /,  MOO,  OIV,  & 

+.  - 

=,  /=,  <,  <=,  >,  >=,  IN 

NOT  (prefix) 

AND 

OR,  XOR 

lowest  precedence 


Within  a  precedence  level,  associativity  Is  left  to  right. 
NOTES 

Arithmetic  Operators 


Arithmetic  operator*  (infix  *,  *,  /,  **,  modulo  (MOD),  inl*|*r  division  (DIV),  and  prefix  ♦,  -)  taka  operand*  of  arithmetic 

types  (INT,  FLOAT,  and  FIXED)  and  return  arithmetic  value*. 

Concatenation  Operator 

A  concatenation  operator  (infix  Jr)  takes  string  and  enumeration  operand*  and  produce*  a  string,  or  takes  one-dimenaional  array 
operand*  and  produce*  a  one-dimentionil  array. 

Relational  Operators 

Relational  operator*  (infix  •,  not  equal  (/*),  <,  <»,  >,  >•,  **t  membership  (IN))  take  arithmetic,  boolean,  enumeration,  string,  and 
•at  operands  and  return  a  boolean.  For  boolean  operands,  only  «  and  /•  are  defined.  For  arithmetic  operand*,  the  relational 
operators  define  a  numerical  ordering.  For  enumeration  and  string  operand*,  the  reletionel  operator*  define  a  collating  sequence. 
For  set  operands,  the  relational  operator*  define  a  subset  relationship. 

Logical  Operators 

Logical  operator*  (infix  AND,  OR,  XOR,  and  prefix  NOT)  take  boolean  operand*  and  produce  a  boolean  or  take  set  operands  end 
produce  n  set  For  boolean  operand*,  the  logical  op»ra!ors  define  and,  or,  exclusive  or,  end  complement.  For  set  operands,  the 
logical  operators  define  set  intersection,  union,  symmetric  difference,  and  complement 

A  type  or  subtype  comparison  ia  one  which  is  used  to  compare  types  or  subtypes  and  returns  a  boolean  value.  Thia  form  of 
expression  is  described  in  Section  4.5.1  and  4.5,2  . 

It  is  possible  to  overload  the  built-in  definition*  of  operator*  to  allow  usar-dafined  operators  (see  Section  1312). 

EXAMPLES 

int_var  X  produces  Integer 

3+4  s  (7  DIV  3 }+2  X  produces  boolean 

'red  >  enum_var  X  produces  boolean 

arrayl(2..4)  &  arrayZ<3..7)  X  produces  array 

setl  AMD  set2  X  produces  set 

(3+1)  DIV  (7-J)  X  produces  Integer 
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expression 


stmt 


referencino  form 


b 

function  Invocation  primary 

25 

H 

attribute  Inouiry 

— 

resolved  constant 
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A  primary  is  the  basic  form  of  an  expression. 

A  t/ariable  can  be  an  entire  variable  or  one  or  more  components  of  a  variable.  A  constant  can  be 
an  entire  constant  or  one  or  more  components  of  a  constant.  A  constant  can  be  either  a  reference  to 
a  c/efined  constant,  written  as  a  literal,  created  by  a  constructor,  the  result  of  a  function,  or  an 
attribute  value. 

A  j.r  b'e  or  constant  which  is  a  component  of  a  record  or  unicn  type  is  referenced  by  dot 
•flection.  An  underlying  dynamic  variable  of  an  indirect  variable  or  constant  (see  Section  4A3>  is 
referenced  by  the  dot  selector  .ALL  A  variable  or  constant  which  is  one  or  more  components  of  an 
array  or  string  is  referenced  by  subscripting  to  produce  a  single  component  or  slice. 

RULES 

I  '  xtifier  l  must  be  associated  with  a  variable  or  constant  in  the  scope  immediately  containing  the 
expression  conta.  "'ng  identifier  i. 

The  result  of  elaboration  of  a  parenthesized  expression  is  the  result  of  elaboration  of  the 
expression. 

NOTES 


Ruins  ♦or  subscripting  am  daseribtd  in  Appandix  C  undar  ARRAY  ond  STRING  typaa.  Rulaa  for  dot  aelaetion  am  daacribad  in 
Appand'w  C  undor  RECORD  and  UNION  typaa  and  in  Saetion  134.  Uaer-dafinad  aubacriptmf  and  dot  sanction  daacribad  in 
Stellon  13  4  Literals  end  constructors  era  daaeribad  in  Saetion  54.  Uaar-dafinad  litarala  and  eonatruetora  am  daacribad  in  Saetion 
135  Function  Invocation  primaries  art  daacribad  in  Saetion  7  2.  Attribute  inquiry  ia  daaerbad  m  Saetion  4.5,3.  Resolved  con  stents 
am  daacribad  in  Saetion  5.7 
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5.4  BUILT-IN  AND  USER-DEFINED  LITERALS  AND  CONSTRUCTORS 


Literals  and  constructors  are  used  to  specify  values  for  variables  and  constants.  Literals  are 
provided  for  specifying  values  of  each  basic  language  type.  For  example, 


TRUE 

'red 

32 

4.53E6 

"This  is  a  string." 


X  a  BOOL  literal 
X  an  ENUM  literal 
X  an  INT  literal 
X  a  FLOAT  literal 
X  a  STRING  literal 


The  literal,  NIL,  is  also  provided  to  specify  a  value  for  all  indirect  types.  Chapter  2  gives  forms  for 
built-in  literals  and  Section  5.5  gives  rules  for  their  types  and  subtypes. 

Values  for  variables  consisting  of  multiple  components  are  written  using  constructors.  For  example, 


VAR  a  :  ARRAY  INK  1..  10)  OF  BOOL; 

VAR  r  :  RECORDt  re,im  :  FLOATU0,  -100.0  ..  100.0)1; 

a  :=  [1  :  FALSE,  2..  10  :  TRUE); 

r  :=  [re  :  3.6,  1m  :  -5.71; 

Section  5.6  gives  rules  for  built-in  constructors. 

Users  can  also  define  literal  and  constructor  forms  for  new  types  (see  Section  13.5).  For  example, 

X  suppose  MILES,  COMPLEX,  and  VSTRING  are  user-defined  types 
X  for  which  user-defined  constructors  are  available 

CONST  d  :=  10.3*MILES; 

VAR  c  :  COMPLEX; 

VAR  v  ;  VSTRING; 

c  :=  Cre  :  0.0,  im  :  2 ,33#COMPLEX; 
v  :=  "This  is  the  value"#VSTRING; 


iwcrmvic  *  ruuo  mw. 
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5.5  MANIFEST  EXPRESSIONS  AND  CONDITIONAL  TRANSLATION 

A  manifest  expression  is  an  expression  whose  value  is  known  during  translation.  The  simplest 
manifest  expression  is  a  literal.  Manifest  expressions  have  two  important  uses:  first,  they  are  used 
to  achieve  conditional  translation  and  second,  they  are  used  as  replacement  elements  for  generic 
parameters  with  value  generic  constraints  (see  Section  1 1.3.4). 

RULES 


Manifest  Expressions 

The  following  are  manifest  expressions: 
a)  any  literal; 

b>  the  result  of  any  of  the  following  built-in  operators  when  their  operands  (actual  parameters) 
are  manifest 

BOOL,  1NT,  FLOAT  operations  --  all,  except  :  = 

ENUM  operations  —  =,  /=,  & 

STRING  operations  —  &,  =,  /=,  component  selection 

c>  a  parenthesized  expression,  where  the  expression  is  a  manifest  expression; 
d>  references  to  constants  declared  with  the  form 

CONST  Id  :=  exp; 

where  exp  is  a  manifest  expression;  and 

e>  references  to  generic  parameters  with  a  value  generic  constraint  (see  Section  1 1.3.4). 

No  other  expressions  are  manifest  expressions. 

All  built-in  arithmetic  operations  in  manifesf  expressions  are  performed  using  the  maximum 
precision  and  range  of  the  target  system. 

Conditional  Translation 

If  the  condition  of  an  if  or  case  statement  is  a  manifest  expression,  code  is  generated  only  for  the 
selected  alternative  body.  Any  translation  time  errors  that  occur  in  those  bodies  not  selected  will  be 
treated  as  warnings  and  will  not  prevent  program  execution. 

If  the  subtype  constraint  (i.e.,  the  tag  value)  of  a  union  subtype  (see  Appendix  C.6)  is  manifest, 
then  only  space  for  that  component  is  reserved. 

NOTES 


Manifest  expreision*  ere  juirenieed  to  be  elebonled  et  treneletion  time;  however,  thie  doe*  not  prohibit  the  treneletor  from 
•Iso  eleboretinj  eny  other  expression  whose  v»lo*  it  een  determine. 

Section  5,7  five*  role*  for  type  end  ei£type  reeolution  of  manifest  expreiiiont. 
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1)  Conditional  translation 

CONST  machine  :=  *  POP 11; 

ABBREV  word  :  UNIONt  S360,  S370  :  b1ts< 32 > , 

P0P11  :  b1ts( 16) , 

CDC6600  :  bl ts< 60 ) 3  (machine); 


IF  machine  =  * PDP11  THEN 
•  «  ♦ 

END  IF; 

•  *  • 

CASE  machine 

WHEN  'S360 ,  'S370  =>  ... 
WHEN  ’ PDP1 1  =>  ••• 

WHEN  'CDC6600  =>  ... 

END  CASE; 
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Constructors  are  used  to  construct  values  for  records,  unions,  arrays,  and  sets. 

RULES 

Values  can  only  be  const'ructed  for  assignable  types. 

For  a  record  or  union  constructor  which  is  resolved  to  a  record  type,  there  must  be  a  value 
specified  lor  each  component  of  the  record  type,  and  the  components  must  be  specified  In  the  same 
order  as  in  the  record  type. 

For  a  record  or  union  constructor  which  is  resolved  to  a  union  type,  there  must  be  a  value 
specified  for  only  one  component  of  the  union  type. 

For  an  array  constructor  which  is  resolved  to  some  array  subtype,  there  must  be  a  single  value 
specified  for  each  component.  The  range  form  is  used  to  specify  a  single  value  for  some  contiguous 
range  of  components. 

For  a  set  constructor  which  is  resolved  to  a  set  type,  there  can  be  zero  or  more  values  specified, 
where  each  value  must  havo  the  component  type  of  the  set.  An  empty  set  constructor  is  the  value  of 
an  empty  set. 

NOTES 


Section  5.7  fives  rulss  for  typs  and  tubtyps  resolution  of  constructors. 


EXAMPLES 

VAR  rl,r2  :  RECORDLw,x  :  INTO..  10), 

y  :  BOOL, 

z  :  ENUHC'a,  'b,  ’c]]; 

VAR  ul,  U2  :  UNION[w,x  :  INTO. .10), 

y  :  BOOL, 

z  :  ENUMC'a,  'b,  'c]3; 

VAR  si,  s2  :  SETfENUMC 'red,  'blue,  'yellow,  'green]]; 
VAR  al,  a2  :  ARRAY  INTO.. 3),  ENUMt'a,  'b,  'c] 


OF  INT <  0 . 

.10); 

VAR 

X 

:  RECOROCa  :  BOOL, 

b  :  SETCINTU 

..10)3, 

c  :  UN ION [d  : 

INT ( 0 . . 

e  : 

BOOL33; 

rl 

= 

[w,  x  :  1,  y  :  FALSE, 

z  :  ’a]; 

r2 

= 

[w  :  1,  x  :  2,  y  :  TRUE,  z  :  ' 

ul 

Cz  :  * b]  ; 

u2 

= 

Cw  :  33; 

si 

s 

['red,  'green]; 

s2 

s 

H; 

al 

“ 

[1,'a  :  0,  1,'b  :  1, 

1,'c  : 

2, 'a  :  3,  2, 'b  :  4, 

2,  'c  : 

3, 'a  :  6,  3,'b  :  7, 

3,  'c  : 

a2 

s 

Cl. .3,  'a..'c  :  103; 

x  :=  [a  :  FALSE,  b  :  £2,3],  c  :  Cd  :  33]; 
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5.7  VALUE  RESOLUTION  AND  USER-DEFINED  VALUES 


The  resob/ed  constant  has  two  purposes:  it  can  be  used  to  create  a  user-defined  literal  or 
constructor;  and  it  can  be  used  to  specify  the  type  or  subtype  of  a  manifest  expression  or  constructor, 
when  the  expression  would  otherwise  be  ambiguous. 

User-Defined  Values 


A  literal  or  constructor  can  be  defined  for  a  user-defined  type  by  overloading  the  definition  of  #. 
This  is  described  in  Section  13.5. 

Type  and  Subtvne  Resolution 

All  expressions  must  have  both  a  type  and  a  subtype.  For  many  kinds  of  expressions ,  the  type  and 
subtype  of  the  expression  depends  only  upon  the  expression  itself.  For  manifest  expressions  and 
constructors,  the  type  and  subtype  may  also  depend  upon  the  context  in  which  the  manifest  expression 
or  constructor  appears.  If  the  context  is  the  right  hand  side  of  an  assignment,  then  the  type  and 
subtype  are  those  of  the  left  hand  side.  For  example, 

VAR  color  :  ENUHI  'red,  'orange,  'blue]; 

VAR  fruit  :  ENUM[  'apple,  'banana,  ’orange]; 

color  :=  'orange;  54,  the  subtype  of  'orange  is 

54  ENUM!  'red,  'orange,  'blue] 

fruit  :=  'orange;  54  the  subtype  of  'orange  Is 

54  ENUMC  'apple,  'banana,  ’orange] 

and 

VAR  r  :  RECORD!  b  :  INT(1..10)J; 

VAR  u  :  UNION!  a.b.c  :  INTU..5)]; 

r  :*  Cb  ;  3];  54  the  subtype  of  [b  :  - 3]  is 

X  RECORD!  b  :  INT41..10)] 
u  :=  lb  :  3];  X  the  subtype  of  lb  :  3]  Is 

54  UNION!  a,b,c  :  INT40..5)] 
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In  some  cases,  the  type  and/or  subtype  of  a  Literal  or  constructor  can  not  be  determined  from  the 
literal  or  constructor  and  its  context.  In  these  cases,  the  type  or  subtype  must  be  explicitly  specified. 

For  example, 

PROC  p  (c  :  color);  X  definition  1 

•  •  • 

END  PROC.  p; 


PROC  p  <f  :  fruit); 
END  PROC  p; 
p  ( 'orange) ; 
p  { 'orange#color) ; 


X  definition  2 

X  Illegal,  ambiguous 
X  legal,  invokes  def  1 


and 


ABBREV  order  1  :  ENUMI'a,  ' b,  'cl; 
ABBREV  order2  :  ENUMt'c,  'b,  'a3; 

VAR  x  :  order  1; 

VAR  y  :  order2 ; 

*  3  ^  *  C  •  «  • 

...  1  a#orderl  <  1  c#orderl 

...  1 a#order2  <  'c#order2 

...  x  <  'b  ... 


X  illegal,  ambiguous 
X  legal,  true 
X  legal,  false 

X  legal,  context  resolves  'b  to 
X  orderl 


Manifest  expressions  can  also  depend  upon  context  for  their  type  and  subtype.  For  example, 


VAR  s  :  5TRING[ASCII]  (5); 

VAR  x  :  FL0AK3,  0.0  ..  100.0); 
VAR  y  :  FL0AK5,  0.0  ..  100.0); 
CONST  pi  :=  3.14149; 


s  :=  "ABC"  &  'CR  &  'LF; 

x  :=  pi ; 
y  :=  pi; 


X  legal,  subtype  of  rlght- 
X  hand  side  Is  resolved  to  subtype  of 
X  left  hand  side 

X  subtype  of  pi  Is  FL0AT(3,  0.0  ••  100.0) 
X  subtype  of  pi  Is  FL0AT(5,  0.0  .♦  100.0) 


The  type  or  subtype  of  a  manifest  expression  or  of  a  constructor  are  resolved  based  on  the  context  in 
which  they  appear.  If  context  is  not  sufficient,  a  default  is  provided  for  integer,  enumeration,  floating 
point,  or  string  values.  In  cases  where  resolution  cannot  be  done  from  the  context  or  default  alone, 
the  resolved  constant  form  can  be  used  to  explicitly  specify  a  type  or  a  subtype. 
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Context  Resolution 

If  a  type  or  subtype  unresolved  expression  appears: 

a>  on  the  right  hand  side  of  an  assignment,  it  is  resolved  to  the  subtyp t  of  the  left  hand  side. 

b>  as  an  actual  parameter ,  it  is  resolved  to  the  specified  type  or  subtype  of  the  corresponding 
formal  parameter,  if  there  is  no  ambiguity. 

c)  within  a  constructor,  it  is  resolved  to  the  component  subtype  of  the  constructed  subtype. 

d)  in  a  resolved  constant  form,  it  is  resolved  to  the  specified  type  or  subtype. 

e>  for  unresolved  float  expressions,  which  appear  as  one  operand  of  a  buiit-ln  binary  float 
operator  (+,  *,  /,  **,  relational),  the  precision  is  resolved  to  be  equal  to  that  of  the  other 

operand. 

Default  Resolution 


When  a  subtype  cannot  be  resolved  from  context,  in  the  following  cases,  a  default  subtype  Is  used. 
For  an  expression  with  value  v,  the  default  subtype  for  various  types  is  shown  below. 


INT 


the  default  subtype  is  lNT(v..v> 


ENUML.l  the  default  subtype  is  ENUMI...1 

FLOAT  the  default  subtype  is  FLOAT(p,v..v>  where  p  is  the  maximum  of  the 

default  precisions  of  all  the  float  literals  that  are  part  of  the  manifest 
expression 

STRINGCENUHC. . .]]  the  default  subtype  is  STRINGtENUMt . . den)  where  len  is  the 

number  of  components  ir«  v 


Explicit  Resolution 

When  a  type  or  a  subtype  cannot  be  resolved  from  context  or  default,  the  manifest  expression  or 
constructor  is  written  as  a  resolved  constant.  The  unresolved  expression  preceding  the  #  is  resolved, 
if  possible,  to  the  type  or  subtype  following  #. 

NOTES 


Tha  raaolvad  eonafant  form  can  alwaya  ba  uaad  lo  raaolva  an  expression  with  at)  ambifuoua  typa  or  aublypa. 
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Statements  fall  into  two  categories:  compound  and  simple.  A  compound  statement  contains  a 
header,  one  or  more  bodies  (with  delimiters  between  bodies ),  and  an  ending.  Any  compound  statement 
can  be  prefixed  and  suffixed  by  matching  identifiers.  These  identifiers  can  serve  as  the  target  of  an 
exit  statement  and,  in  addition,  enhance  program  readability.  Each  compound  statement  is  an  open 
scope.  The  only  definitions  which  are  local  to  a  compound  statement  are  the  matching  identifiers  and, 
in  the  case  of  a  repeat  statement,  the  index  variable.  Notice,  however,  that  each  body  contained  In  a 
compound  statement  is  a  scope  that  may  contain  local  definitions.  A  simple  statement  does  not  contain 
a  body,  cannot  be  surrounded  by  matching  identifiers,  and  is  not  a  scope.  Any  statement  may 
optionally  be  preceded  by  labels  that  can  serve  as  the  target  for  a  goto  statement. 

RULES 

Identifier  1  is  called  a  goto  label  and  is  defined  in  the  scope  Immediately  containing  the  statement 
it  prefixes. 

Identifiers  2  and  3,  called  matching  identifiers,  must  be  identical.  The  matching  Identifier  is  defined 
In  the  scope  of  the  compound  statement  which  it  brackets. 

NOTES 


Goto  label*  and  matching  identifiers  irt  automatically  inharilad  by  open  acopca  (*••  Section  3.5}  but  are  never  inherited  by 
doted  acopea  and  may  never  be  exported  from  a  capsule  (see  Saction  3.2).  A  matching  M?ei -cm  never  bo  the  target  of  t  goto 
atatement,  and  a  goto  label  can  never  be  the  targot  of  an  exit  statement. 

Even  though  there  it  no  "empty  ititement",  empty  boditt  tre  permitted  (fee  Section  32). 
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64  ASSIGNMENT  STATEMENT 


The  assignment  statement  is  used  to  copy  the  value  of  an  expression  into  a  variable . 

RULES 

The  expression  must  have  the  same  type  as  the  variable ;  that  type  must  be  assignable  (see  Section 
4.3). 

Elaboration  of  the  assignment  statement  replaces  the  current  value  of  the  variable  with  the  value 
of  the  expression. 

The  value  of  the  expression  must  satisfy  any  subtype  constraints  of  the  variable  (e.g.,  range, 
precision,  array  bounds >;  otherwise,  the  appropriate  exception  is  raised. 

NOTES 

Enlir*  array*,  array  alicaa,  and  racorda  may  b*  aaaifnad  in  a  ainfi*  aa*ifnm<*nl. 

For  rulaa  concnrnmg  tha  ainjnmtni  of  built-in  typaa,  it*  Appandi*  C.  For  rul*a  eoncarnmf  aaaifnmanl  of  uaar-dafinud  typaa, 
tee  Saction  13.2. 

EXAMPLES 

VAR  x,y  :  INK  1 . .  10) ; 

VAR  al,a2  :  ARRAY  INTU..10)  OF  BOOL; 

al  :=  f < a  1 ) ; 

a2  •  s  a 1  *  * 

aid.  .5)’:=  a2(3.  .7); 

'<  :  =  3 ; 
y  ;s  x  ♦  1; 
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The  begin  statement  can  be  used  to  group  together  a  sequence  of  related  statements.  Since  the 
begin  statement  introduces  a  new  open  scope,  it  is  also  a  convenient  means  for  localizing  declarations 
to  the  sequence  of  statements  where  they  are  needed. 

RULES 

The  begin  statement  is  elaborated  by  elaborating  its  body. 

NOTES 


All  compound  declarations  and  compound  statements  contain  bodies.  It  is  lb* rotor*  unnscsssary  to  writ#  •  begin  statement  in 
thoM  contexts  in  ontar  to  achisvo  troupinf  of  multiple  statements  into  ■  oingl#  statement  or  to  scnisve  •  n*w  scope  for 
declarations. 

EXAMPLES 

BEGIN 

X  swap  record  components 

VAR  x  :  RECORD  Ea,b  :  INT( 1 . . 10 > 3 ; 

READ  (Inf tie,  x); 

BEGIN 

CONST  t  :=  x.a; 
x .a  :=  x.b; 
x.b  :=  t; 

END; 

WRITE  (outflle,  x); 

END;  . 
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The  if  statement  selects  one  of  several  alternative  bodies  for  elaboration,  based  on  the  value  of 
one  or  more  boolean  expressions. 


Each  expression  must  have  type  BOOL 

Elaboration  of  an  if  statement  proceeds  by  elaboration  of  each  expression  in  order  until  either  an 
expression  with  value  true  or  a  final  ELSE  is  reached;  then  the  corresponding  body  is  elaborated.  If 
no  expression  has  value  true  and  no  final  ELSE  is  present,  none  of  the  bodies  Is  elaborated. 


INTERMETRICS  INC. 
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IF  x  <  y  THEN 
CONST  t  :=  x; 
x  :=  y; 
y  :*  t; 

END  IF; 

IF  1  <  ”j  THEN 
k  :=  1; 

ELSE 

k  :=  j; 

END  IF; 

IF  flag  THEN 
1  :=  1  +  I; 
ELSEIF  J  <  0  THEN 
1  :=  1; 

ELSEIF  k  <  0  THEN 
1  :=  2; 

ELSE 

1  :=  1  -  1; 

END  IF; 
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The  case  statement  allows  a  body  to  be  selected  for  elaboration  from  one  or  more  alternate 
bodies,  based  on  the  value  of  a  single  expression. 

RULES 

Between  each  WHEN  and  is  a  list  of  value  labels.  A  value  label  can  be  either  an  expression  (a 
§ioaie..-Va[ue  Jabgj),  or  a  range  (a  range  value  label).  The  expressions  in  all  value  labels  and  the 
expression  following  CASE  must  be  of  the  same  type.  If  only  single  value  labels  appear,  the  type  must 
be  one  for  which  =  is  defined.  If  any  range  value  labels  appear,  the  type  must  be  one  for  which  *  and 
<  are  defined. 

Elaboration  of  a  case  statement  consists  of  the  following  steps: 

a)  The  value  of  the  expression  following  CASE  is  compared  to  the  values  of  the  value  labels.  A 
match  is  found  if  the  value  of  the  CASE  expression  is  either  equal  to  the  value  of  a  single  value 
label  or  is  within  the  range  of  a  range  value  label  (see  Section  4.1.7).  The  order  in  which  value 
labels  are  examined  is  undefined. 

b)  If  one  or  more  matches  are  present,  then  the  body  associated  with  one  of  the  matching  * _ e 

labels  is  elaborated. 

c)  If  no  match  is  found  and  the  ELSE  is  present,  the  body  following  ELSE  is  elaborated. 


d>  If  no  match  Is 


X_CASE  exception  Is  raised. 


found  and  the  ELSE  is  not  present,  the 


NOTES 

Whtn  mor.  th.n  on.  m.«ehinf  v.lu. 
Iab.1.  wilt  bo  .tabor.fod. 


MmI  i.  found,  it  c.nnot  b.  predict*!  which  of  th. 


todies  ...oci.Ud  with  th.  m.tehinf 


U.«  of  th.  ctse  statement  for  user 


defined  type*  i*  d.*cfb«d  in  Soellon  13.8. 


EXAMPLES 

VAR  1  :  INT  < - 10 . . 10 ) • 


CASE  1 

WHEN  0 

WHEN  -10.. -1 
WHEN  1..5 
ELSE 

END  CASE; 


=>  s 
=  >  s 
=>  s 
=>  s 


"ZERO" ; 
"NEG"; 
"SMALL" ; 
"LARGE"; 


VAR  u 


UNION  [ 

a  :  INTO.  .101* 


b  :  BOOL, 
c  :  INT(-5. .5)  1 


CASE  u .TAG 

WHEN  'a  =>  u.a 
WHEN  ‘b  =>  u-b 
WHEN  'c  =>  u.c 
END  CASE; 


u.a  ♦  1; 
NOT  u.b; 
-u.c; 


CASE  TRUE 

WHEN  1>=J  =>  max 
WHEN  J>=1  => 

END  CASE; 


i; 

i; 
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The  repeat  statement  a!<ows  a  body  to  be  elaborated  zero  or  more  times.  The  for  phrase  has  an 
index  that  takes  on  successive  values  of  the  specified  subtype.  The  while  phrase  is  used  to  achieve 
conditional  repetition. 

RULES 

For  Phrase 

The  identifier,  called  the  index,  is  defined  as  a  variable  with  the  specified  subtype  in  the  scope  of 
the  repeat  statement.  The  index  is  treated  as  a  readonly  data  item  within  the  body  (see  Section  4.2). 

Elaboration  of  a  repeat  statement  with  for  phrase  proceeds  as  follows.  The  index  is  created 
before  the  first  repetition.  During  the  first  repetition,  the  index  has  the  lowest  value  of  the  subtype 
(i.e.,  ,MIN>.  For  each  subsequent  repetition,  the  index  will  have  the  successive  value  of  the  subtype 
(via  SliCC)  until  the  last  value  (.MAX)  is  reached.  If  REVERSE  is  specified,  the  index  has  the  value 
•  MAX  for  the  first  repetition,  and  has  successive  values  (via  PRED)  until  the  last  value  (.MIN)  is 
reached. 

While  Phrase 


The  expression  must  have  type  BOOL.  Elaboration  of  the  repeat  statement  with  a  while  phrase 
repeatedly  elaborates  the  body  while  this  expression  is  true.  The  value  of  the  expression  is  tested 
prior  to  each  elaboration  of  the  body. 
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Tha  indax  is  local  lo  lha  repeat  statement,  i.a.,  naithar  ill  definition  nor  ill  valua  it  directly  available*  ootaida  lha  repeat 
a iatamnnt  If  lha  subtype  of  lha  indax  haa  no  valuaa  lha  body  ia  nol  elaboralad. 

Additional  larminalion  condition!  can  b*  inaarlad  anywhora  within  lha  body  of  a  repeat  statement  by  lha  conditional  uaa  of  an 
exit  statement  (n*a  Saclion  8.5). 

Uaa  of  lha  repeat  statement  for  user-defined  types  ia  daaerbad  in  Saelior.  ia7. 


EXAMPLES 

r  :=  0; 
q  :=  0; 

WHILE  y  <=  r  REPEAT 
r  :=  r  -  y; 

q  :*  q  +  lj 

END  REPEAT; 

VAR  a  :  ARRAY  INTU..n)  OF  INT<i..n); 
FOR  1  :  INTO,  .n)  REPEAT 
a<1)  1; 

END  REPEAT; 
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The  exit  statement  terminates  the  elaboration  of  an  enclosing  compound  statement. 


RULES 


The  identifier  must  be  Known  as  a  matching  identifier. 

Elaboration  of  the  exit  statement  causes  the  elaboration  of  the  compound  statement  bracketed  by 
the  matching  identifier  to  be  terminated. 

NOTES 


An  exit  statement  cannot  ba  uaad  to  trantfar  control  out  of  a  compound  declaration  (procadura,  function,  ate),  ainea  matehinf 
Wanttfiari  ara  navat  inharitad  by  cloaad  acopaa. 


EXAMPLES 

j  :  =  0  ; 

search’ FOR  i  :  INT(l..n>  REPEAT 
IF  ad)  a  »  THEN 
)  :=  1; 
i*XI"  search; 

END  IF; 

END  REPEAT  search; 
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6.7  RETURN  STATEMENT 


The  return  statement  terminates  the  invocation  of  a  compound  declaration  (i.e.»  procedure, 
function,  task,  or  capsule). 

RULES 

Elaboration  of  a  return  statement  causes  elaboration  of  the  smallest  enclosing  procedure,  function, 
task,  or  capsule  to  be  terminated. 

Expression  must  be  present  if  the  terminated  construct  is  a  function  and  may  not  be  specified  for 
any  other  construct.  The  type  of  the  expression  :iiust  be  the  same  as  that  of  the  function  result  (see 
Section  7.2). 

NOTES 


A  return  statement  i*  not  naadtd  for  procedure*,  tasks,  and  eapsuloa  whoso  only  "return  point*  is  st  tha  snd  of  tha  body.  The 
elaboration  of  a  function  must  tsrminsts  throufh  •  return  statement  (or  by  reiaint  an  exception). 


EXAMPLE 

FUNC  search  (a  :  ARRAY  INT  OF  INT,  v  :  INT)  =>  IHDEXOF ( a ) ; 
FOR  t  :  INDEXOF(a)  REPEAT 
IF  a(1>  =  v  THEN 
RETURN  1 ; 

END  IF; 

END  REPEAT; 

RAISE  searcb_fa11ure; 

END  FUNC  search; 
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6.8  GOTO  STATEMENT 


The  goto  statement  causes  elaboration  to  continue  at  a  specified  statement. 

RULES 

The  identifier  must  be  known  as  a  goto  label.  Elaboration  of  the  goto  statement  causes 
elaboration  to  continue  at  the  statement  labeled  by  the  goto  label. 

NOTES 

Becauta  tha  goto  labal  of  tha  target  atatamant  mutt  ba  local  or  daclarad  in  an  ancloting  scop*,  no  tranafar  it  ailowad  into 
bodies  or  batwaan  altarnativaa  of  an  if  or  cose  statement. 

A  goto  statement  cannot  ba  uatd  to  tranafar  control  out  of  a  compound  declaration  (la,  procadura,  function,  ate),  tinea  goto 
labslt  ara  navnr  ink''"  )d  by  cloaad  tcopat. 

EXAMPLE 

sort  }  1  :  INT(l..n-l)  REPEAT 

a( 1 )  >  a( 1+1)  THEN 

CONST  t  :=  a<1);  * 

a <  i >  :=  a(i+l); 
a<1+l)  :=  t; 

GOTO  sort; 

END  IF; 

END  REPEAT; 
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7.  PROCEDURES,  FUNCTIONS,  AND  PARAMETERS 

Procedures  and  functions  are  major  language  features  for  modularizing  programs.  Procedures  and 
functions  are  defined  by  deferred  declarations.  Since  procedures  and  functions  are  deferred  units, 
they  are  elaborated  when  Hhey  are  invoked,  rather  than  when  their  declaration  is  encountered. 

A  procedure  is  elaborated  when  a  procedure  invocation  statement  occurs.  A  function  is  elaborated 
when  a  function  invocation  occurs  in  an  expression. 

Procedures  and  functions  may  be  parameterized;  when  they  are,  actual  parameters  are  bound  to 
corresponding  formal  parameters  of  the  procedure  or  function  declaration  at  the  time  of  invocation. 
This  correspondence  is  based  on  the  positions  of  the  parameters  in  the  formal  and  actual  parameter 
lists. 

Procedure  and  function  declarations,  like  all  deferred  declarations,  are  closed  scopes.  Any 
variables  from  the  enclosing  scope  used  by  a  procedure  or  function  must  be  explicitly  Imported. 
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7.1  PROCEDURE  DECLARATION  AND  INVOCATION 


A  procedure  is  invoked  by  a  procedure  invocation  statement  to  perform  some  action. 


im  cnivic.!  mioa  uxo. 


section  /.x 


XDl 


RULES 


Identifier  or  definable  symbol  1  is  defined  fo  be  a  procedure  in  the  scope  in  which  the 
procedure  declaration  appears.  Identifier  or  definable  symbol  2  must  be  identical  to  identifier  or 
definable  symbol  1. 

Elaboration  of  a  procedure  invocation  statement  proceeds  in  the  following  order: 
a)  actual  parameters  are  elaborated; 

b>  actual  parameters  are  bound  to  the  formal  parameters  of  the  named  procedure  (see  Section 
7.3>,  and 

c>  the  body  of  the  named  procedure  is  elaborated. 

NOTES 


A  procedure  dedoretbn  i*  •  doted  aenpe  (»»*  Section  3.5);  the  formal  parameter  names  are  defined  in  thi*  ecope. 

Procedure*  may  be  overloaded  and  may  be  (aneric.  Overloading  janariea,  and  u*e  of  the  trsnatatlon  time  property  lift  ere 
diecutaed  in  Chapter  1 1  Uae  of  definable  eymbol  name*  i*  ditcutcad  if.  Section  132. 

The  order  in  which  sctusl  psrsmeters  are  elaborated  and  bound  i*  untpecified. 

EXAMPLE 

PROC  swap  (VAR  x,y  :  IUTi; 

CONST  t  :=  x; 
x  :=  y; 
y  :*  t; 

END  PROC  swap; 
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7.2  FUNCTION  DECLARATION  AND  INVOCATION 


Section  7.2 
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A  function  differs  from  a  procedure  in  that  a  function  produces  a  result,  a  temporary  data  item 
(see  Section  5.1).  This  result  is  obtained  during  elaboration  of  the  body  by  elaborating  a  return 
statement  which  specifies  the  value  of  the  result  to  be  produced.  A  function  Is  elaborated  when  a 
function  invocation  occurs  as  an  operand  in  an  expression. 


RULES 

Identifier  or  definable  symbol  l  is  defined  to  be  a  function  in  the  scope  in  which  the  function 
declaration  appears.  Identifier  or  definable  symbol  2  must  be  the  same  as  identifier  or  definable 
symbol  J. 

The  type  or  subtype  following  =>  is  known  as  the  result  type  or  subtype.  The  result  type  or  the 
type  of  the  result  subtype  must  be  assignable. 

Elaboration  of  a  function  invocation  primary  proceeds  in  the  following  order: 
a>  actual  parameters  are  elaborated; 

b)  actual  parameters  are  bound  to  the  formal  parameters  of  the  named  function  (see  Section  7.3  V, 

c>  the  body  of  the  function  is  elaborated  until  a  return  statement  is  encountered; 

d>  a  result  temporary  data  item  is  created,  whose  subtype  is  the  result  subtype  (if  specified)  or 
the  subtype  of  the  expression  in  the  return  statement  (if  a  result  type  is  specified);  and 

e)  the  result  of  the  function  is  produced  by  assigning  (via  :*)  the  value  of  the  expression  in  the 
return  statement  to  a  result  temporary  data  item.  The  :*  definition  used  is  the  one  known  in 
the  scope  where  the  function  is  defined. 

There  must  be  no  way  to  reach  the  point  immediately  after  the  last  statement  In  the  body  of  the 
functnn,  i.e.,  elaboration  must  always  complete  by  the  use  of  a  return  statement. 

Additional  rules  for  the  return  statement  are  given  in  Section  6.7,  and  (for  side-effects  and 
normality  of  functions)  in  Section  7.2.1. 

NOTES 

A  function  declaration  i*  e  cloud  acope  Section  3.5).  the  formal  paremsler  namaa  and  lha  reault  variable  tra  dafinad  In  this 
acopa. 

The  reault  aubtype  may  depend  on  the  subtypes  and  veluea  of  fha  actual  parameters. 

Functions  may  ba  overloaded  and  may  be  jcnaric.  Overloading,  generic*,  and  the  uaa  of  fha  tranalafion  time  property  liat  la 
diacuaead  in  Chapter  1 1  Uaa  of  definable  aymbol  namaa  is  ditcuistd  in  132. 

The  order  in  which  actual  parameters  are  elaborated  and  bound  ia  unapeeifieA 


EXAMPLE 

FUNC  hypot(sidel ,  sldeZ  :  FLOAT)  =>  FLOAT; 

RETURN  sqrt  <s1del**2  +  s1de2**2>; 

END  FUNC  hypot; 
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7.2.1  NORMALITY  AND  SIDE-EFFECTS 

There  are  two  kinds  of  functions:  normal  and  abnormal  functions.  The  result  of  the  invocation  of 
a  normal  function  depends  only  upon  the  values  of  the  actual  parameters.  Several  invocations  of  a 
normal  function  with  the  same  actual  parameter  values  may  be  replaced  by  the  translator  with  e  single 
invocation  (this  is  called  common  subexpression  elimination).  The  result  of  the  Invocation  of  an 
abnormal  function  can  depend  upon  the  values  of  variables  other  than  those  in  the  actual  parameters. 
All  abnormal  functions  should  be  preceded  by  the  reserved  word  ABNORMAL.  Both  abbreviations  and 
types  are  assumed  to  be  normal;  the  result  of  invoking  an  abbreviation  or  type  should  depend  only 
upon  the  values  of  the  actual  parameters. 

A  function  is  said  to  have  a  side-effect  if  the  function  modifies  any  data  whose  lifetime  is  longer 
than  the  function  invocation.  Programs  are  more  understandable,  reliable,  and  verifiable  when 
functions  have  no  side-effecls.  However,  there  are  cases  where  having  side-effects  is  useful.  The 
language  allows  normal  functions  to  have  side-effects  providing  these  side-effects  are  restricted  to 
modifications  of  data  items  that  are  local  to  the  body  of  a  capsule  in  which  the  function  is  also  local. 
For  normal  functions  with  side-effects,  the  user  must  ensure  that  any  common  subexpression 
elimination  will  not  have  an  undesired  effect  upon  program  behavior. 

RULES 

The  order  of  elaboration  within  expressions  is  not  defined.  This  means  that  the  order  in  which 
side-effects  occur  within  expressions  is  not  guaranteed. 

If  more  than  one  exception  could  be  raised  while  elaborating  an  expression,  which  of  these 
exceptions  is  actually  raised  is  not  defined. 

If  there  are  several  invocations  anywhere  in  a  program  of  a  normal  function,  a  type,  or  an 
abbreviation  whose  corresponding  actual  parameters  have  the  same  value,  these  Invocations  may  be 
replaced  (by  a  translator)  by  a  single  invocation  which  occurs  at  the  point  of  the  first  of  these 
invocations. 

A  normal  function  may  have  only  CONST  and  READONLY  formal  parameters. 

If  a  normal  function  has  an  imports  list,  then: 

a)  the  function  must  be  local  to  a  capsule  body, 

b)  variables  imported  by  the  function  must  be  defined  locally  In  the  capsule  body  in  which  the 
function  is  local; 

c)  no  invocations  of  the  function  may  appear  anywhere  within  the  capsule  in  which  the  function  Is 
defined;  and 

d)  no  variables  imported  by  a  normal  function  may  be  exported  from  the  capsule. 

NOTES 


Failure  to  mark  an  abnormal  function,  or  the  protanca  of  an  abnormal  tbbravialion  or  type,  meana  that  common  aubexpreaelon 
elimination  may  produce  undeaired  raaulla. 

The  only  normal  functiona  which  have  no  paramalara  are  funetiona  which  alwaya  produce  the  earn#  conatant  value. 
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1)  A  normal  function  with  no  side-effects 


FUNC  fact  (1  :  INT)  *>  INTU.  .10000); 

IF  1  = ‘0  THEN  RETURN  1; 

ELSE  RETURN  1  *  fact(i-l); 

END  IF; 

END  FUNC  fact; 

2)  A  normal  function,  fact,  with  a  restricted  side-effect  which  records  the  number  of  times  It  Is 
called.  This  count  is  returned  by  an  abnormal  function,  factcnt. 

CAPSULE  c  EXPORTS  fact,  factcnt; 

VAR  cnt  :  INT(0. .10000)  :=  0; 

FUNC  fact<1  :  INT)  =>  INTO.  .10000)  IMPORTS  cnt; 

X  The  result  depends  only  on  the  value  of 
X  the  parameter,  1. 

VAR  r  :  INTO .  .10000)  :*  1; 
cnt  :=  cnt  +  1; 

FOR  j  :  INTU..1)  REPEAT 

END  REPEAT;  ^ 

RETURN  r; 

END  FUNC  fact; 

ABNORMAL  FUNC  factcnt  *>  INT(0. . 10000)  IMPORTS  cnt; 

X  The  result,  r,  Is  not  computed  based  only  upon  the 
X  parameters  (of  which  there  are  none). 

RETURN  cnt; 

END  FUNC  factcnt; 

END  CAPSULE  c; 

3)  A  normal  function  with  a  restricted  side-effect  --  a  memo  function 

CAPSULE  fmemo  EXPORTS  f; 

VAR  oldx  :  INTO..  100)  :=  1; 

VAR  oldy  :  INTU. .100)  :s  realf  (oldx); 

FUNC  f  ( x  :  INTU. .100))  =>  INTU. .100)  IMPORTS  oldx,  oldy; 

IF  x  /=  oldx  THEN 
oldx  :=  *; 

oldy  :=  realf  (oldx); 

END  IF; 

RETURN  oldy; 

END  FUNC  f; 

FUNC  realf  (x  ;  INTO..  100 >)  *>  INTO..  100); 

END  FUNC  realf; 


END  CAPSULE  fmemo; 
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4)  An  abnormal  random  number  generator  function 


CAPSULE  randcap  ( 1n1tial_seed  :  INI)  EXPORTS  random; 

VAR  seed  :  INK-1000. .1000)  :*  Initialled; 

ABNORMAL  FUNC  random  *>  INK -1000..  100S)  IMPORTS  seed; 
seed  :=  next(seed); 

RETURN  seed; 

FUNC  next  (1  :  INK-1000.  .1000))  =>  INK-1000.  .1000) ; 

X  computes  next  random  number 
END  FUNC  next; 

END  FUNC  random; 

END  CAPSULE  randcap; 

5)  A  symbol  table 

CAPSULE  symtab  EXPORTS  look_up; 

CONST  size  :=  500; 

ABBREV  sym  :  STRINGtASCII]  (8); 

VAR  limit  :  INT < 0 . .size)  :=  0; 

VAR  table  :  ARRAY  INK  1.. size)  OF  sym; 

ABNORMAL  FUNC  1ook_up  (s  :  sym)  =>  INT(0..s1ze) 

IMPORTS  READONLY  limit,  READONLY  table; 

FOR  1  :  INK  1.. size)  REPEAT 
IF  tabled)  =  s  THEN 
RETURN  1; 

END  IF; 

END  REPEAT;  • 

RETURN  0; 

END  FUNC  look_up; 

FUNC  insert  (s  :  sym)  =>  INT(l..s1ze) 

IMPORTS  limit,  table; 

CONST  1  :=  lookup  (s); 

IF  1  /=  0  THEN 
RETURN  1; 

ELSE 

limit  :=  limit  ♦  1; 
table  (limit)  :*  s; 

RETURN  limit; 

END  IF; 

END  FUNC  Insert; 

END  CAPSULE  symtab; 
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Parameters  are  used  to  pass  information  between  a  specific  invocation  of  a  deferred  unit  (i.e.,  a 
procedure,  function,  task,  capsule,  type,  or  abbreviation)  and  the  deferred  unit. 

When  a  deferred  declaration  specifies  a  list  of  formal  parameters,  each  invocation  of  the  deferred 
unit  defined  by  the  declaration  must  then  supply  an  actual  parameter  for  each  formal  parameter . 
When  the  deferred  unit  is  invoked,  each  formal  parameter  is  bound  to  its  associated  actual  parameter. 
The  kind  of  binding  is  specified  for  each  formal  parameter  by  means  of  a  binding  class. 

There  are  four  binding  classes:  two  for  passing  information  into  a  deferred  unit  (CONST  and 
READONLY);  one  for  passing  information  out  (OUT);  and  one  for  passing  information  both  In  and  out 
(VARX 
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RULE5 

Association  of  Actual  and  Formal  Parameters 

The  number  of  actuaf  'parameters  in  an  invocation  must  be  equal  to  the  number  of  formal 
parameters  of  the  invoked  deferred  unit.  Actual  parameters  are  associated  with  formal  parameters 
positionally. 


Type  Checking 

Each  actual  parameter  must  have  the  same  type  as  that  specified  for  the  corresponding  formal 
parameter  (or  the  type  of  the  subtype  specified). 


finding  of  Actual  Parameters  to  Formal  Parameters 

If  a  formal  parameter  specifies  a  type,  if  acquires  the  subtype  of  the  actual  parameter  with  which 
it  is  bound. 

If  a  formal  parameter  specifies  a  subtype,  the  formal  parameter  has  that  subtype ;  if  the  binding 
class  is  VAR  or  READONLY  the  actual  parameter  must  have  an  equal  subtype  (otherwise  the  X_SUBTYPE 
exception  is  raised). 

The  binding  class  is  CONST  when  no  binding  class  is  explicitly  specified.  The  actual  parameters 
associated  with  VAR  and  OUT  formal  parameters  must  be  variables.  For  CONST  and  OUT,  the  parameter 
must  have  a  type  for  which  assignment  is  defined.  Rules  for  each  binding  class  are  given  here.  . 


CONST  The  formal  parameter  Is  a  local  constant  to  which  the  value  of  the  actual 

parameter  is  assigned  (via  :=). 

VAR  The  formal  parameter  is  a  local  name  for  the  actual  parameter  variable. 

OUT  The  formal  parameter  is  a  local  variable  which  is  assigned  (via  :»)  to  the  actual 

parameter  variable  upon  normal  completion  (i.e.,  completion  other  than  as  the 
result  of  an  unhandled  exception)  of  the  invocation. 


READONLY  The  formal  parameter  is  a  local  name  for  the  actual  parameter.  The  formal 

parameter  is  treated  as  a  readonly  data  item. 

For  CONST  and  OUT  formal  parameters,  the  definition  of  assignment  used  is  one  known  in  the 
cope  where  the  formal  parameter  definition  appears. 

Order  of  Binding 


The  order  in  which  actual  parameters  are  bound  to  formal  parameters  is  undefined.  A  subtype 
specified  for  a  formal  parameter  may  not  depend  upon  the  value  or  subtype  nL  other  formal 
parameters. 
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Capsules  are  the  basic  unit  of  separate  translation  (see  Section  3.1)  and  can  also  be  nested  within 
other  language  constructs.  Capsules  can  be  used  to  create  common  data  pools,  libraries,  and  abstract 
data  types,  as  well  as  independent,  executable  programs. 

A  capsule,  like  a  procedure,  is  a  deferred  unit  which  is  invoked.  Capsules  differ  from  procedures 
in  that  definitions  local  to  a  capsule  body  may  be  made  known  outside  it.  Selected  definitions  can  be 
made  locally  known  in  each  scope  where  the  capsule  is  invoked.  The  body  of  a  capsule  can  contain 
statements  as  well  as  definitions.  These  statements  are  elaborated  to  initialize  variables  and  constant* 
defined  in  the  capsule. 

There  are  two  ways  in  which  a  capsule  can  be  invoked. 

1)  It  can  be  invoked  as  new.  Each  such  invocation  will  cause  the  capsule  to  be  elaborated.  Local 
variable  and  constant  declarations  in  the  capsule  body  create  different  variables  and  constants 
at  each  new  invocation.  Capsules  invoked  as  new  may  be  parameterized.  Actual  parameters 
are  supplied  each  time  a  capsule  is  invoked  and  serve  to  specialize  the  capsule. 

2)  It  can  be  invoked  as  old.  In  this  case,  all  old  invocations  will  reference  a  single  version  of  the 
capsule  which  was  elaborated  upon  entry  to  the  scope  where  the  capsule  was  defined.  Each 
old  invocation  will  reference  the  same  set  of  variables  and  constants  from  the  capsule.  Capsules 
which  are  invoked  as  old  may  not  have  parameters. 


NOTES 


Dafmitiona  that  ara  known  in  a  acopa  coma  from  thra*  aourcaa.  local  dafimtiona  written  in  tha  acopa,  dafinitiona  which  baeoma 
locally  known  by  invokini  a  capaule  in  that  acopa,  and  dafimtiona  which  ara  availabla  (althar  implicitly  or  throuyh  an  Importa  list) 
from  lha  andoainf  aeopo. 
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A  capsule  declaration  is  invoked  to  make  selected  definitions  in  Its  body  known  in  the  scopes 
where  Invocations  of  the  capsule  appear. 

RULES 

Capsule  Declaration 

Identifier  1  in  a  capsule  declaration  is  defined  to  be  a  capsule  in  the  scope  in  which  the  capsule 
declaration  appears.  Identifier  2  must  be  the  same  as  identifier  l. 

A  capsule  declaration  which  is  invoked  as  old  or  which  is  a  translation  unit  may  not  ,  /e  any 
formal  parameters.  A  capsule  may  not  have  formal  parameters  of  the  OUT  binding  class. 

Capsule  Invocation  Declaration 

The  capsule  with  name  identifier  l  is  invoked. 

The  lifetime  of  actual  parameters  passed  to  RC^uONLY  and  VAR  for  'I  parameters  must  be  greater 
than  or  equal  to  the  lifetime  of  the  capsule  invocation  declaration  containing  those  actual  parameters. 

n  capsule  invocation  declaration  has  two  effects:  it  causes  elaboration  of  a  capsule  declaration 
and  it  makes  selected  definitions  visible.  There  are  two  ways  in  which  a  capsule  may  be  invoked: 

a)  As  a  new  invocation  (if  NEW  is  specified). 
b>  As  an  old  Invocation  (if  NEW  is  not  specified). 

Elaboration  of  a  new  capsule  invocation  declaration  consists  of 
a)  elaborating  the  actual  parameters; 

b>  binding  the  actual  parameters  to  the  formed  parameters  of  the  invoked  capsule  (see  Section  7.3); 
and 

c)  elaborating  the  body  of  the  invoked  capsule. 

If  there  are  any  old  invocations  of  a  capsule,  the  body  of  the  invoked  capsule  is  elaborated  once 
upon  entry  to  the  scope  in  which  the  capsule  declaration  appears. 

A  capsule  invocation  declaration  makes  selected  definitions  that  are  locally  known  in  the  body  of 
the  capsule  also  locally  known  in  the  scope  where  an  invocation  of  the  capsule  appears  (see  Section 
8.2).  For  new  invocations,  these  definitions  are  the  ones  that  have  been  created  during  elaboration  of 
the  capsule  invocation  declaration.  For  old  invocations  thp'e  definitions  are  the  ones  that  were 
created  upon  entry  to  the  scope  where  the  capsule  declaratio  appears. 

The  lifetime  of  any  definitions  made  known  by  a  new  capsule  invocation  declaration  is  equal  to  the 
lifetime  of  the  capsule  invocation  declaration.  The  lifetime  of  any  definitions  made  known  by  an  old 
capsule  invocation  is  equal  to  the  lifetime  of  the  declaration  of  the  invoked  capsule. 

If  an  invocation  includes  a  RENAMING  list,  there  must  be  a  definition  known  <as  a  result  of  the 
visible  list)  for  each  identifier  2  and  definable  symbol  2  that  appears.  For  each  item  in  the  list  of  the 
form 


name  2  TO  name  3 
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aii  definitions  that  would  be  known  as  name  2  are  known  instead  as  name  3  in  the  scope  where  ihe 
capsule  invocation  declaration  appears,  tf  name  3  is  a  definable  symbol,  all  definitions  of  name  2  must 
satisfy  all  restrictions  upon  definitions  of  that  definable  symboL 

If  EXTERNAL  is  specified,'  then  Ldentifie  1  must  be  the  name  of  some  separate  translation  unit.  If 
EXTERNAL  is  not  specified,  a  definition  for  identifier  !  must  be  known  in  the  scope  in  which  the 
capsule  invocation  declaration  appears. 

If  there  are  several  capsule  invocation  declarations  local  to  the  same  scope,  then  none  of  these 
declarations  may  contain  any  uses  of  the  definitions  that  it,  or  any  later  capsule  invocation 
declaration,  makes  known. 

NOTES 


A  capsule  declaration  is  the  only  language  construct  to  include  an  exports  list. 

A  capsule  declaration  is  e  elossd  scops.  TKs  only  definitions  which  srs  focal  to  s  capsule  declaration,  ss  opposed  to  ths  body  of 
tha  cspsuls,  srs  formal  paramslsr  definitions  (sat  Sselion  3.5). 

Variables  dsclarsd  in  ths  cspsuls  that  are  not  sxporlsd  act  ss  "own"  data  of  ths  capsuls.  Lihs  all  data  in  ths  capsule,  aueh 
variables  corns  into  axis tsnes  each  time  ths  body  of  ths  capsule  is  elaborated;  tha  statements  in  ths  capsuls  body  may  be  used  to 
initialize  them. 

Translation  time  property  lists  are  used  to  overload  capsules  and  to  ersata  generic  capsules. 

EXAMPLES 

1)  Common  group  of  declarations. 

CAPSULE  device_tab1es  (ntty  :  INT,  nprlnt  :  INT)  EXPORTS  ALL; 

CONST  console  1; 

VAR  tty_tab  :  ARRAY  INK  1  ..  ntty)  OF  ity_1nfo; 

VAR  pr1nter_tab  :  ARRAY  INT ( 1  ..  nprlnt)  OF  pr1nt_1nfo; 

FOR  i  :  INT <  1  ..  ntty)  RF.PEAT 
1n1t_tty  (tty_tab(  1 ),  1); 

END  REPEAT; 

FOR  i  :  INK  1  ..  nprlnt)  REPEAT 

1n1t_printer  (printer_tab( 1 ),  1); 

END  REPEAT; 

END  CAPSULE  dev1ce_tables; 


%  Typical  use 

EXPOSE  ALL  FROM  NEW  dev1ce_tables  (10,2); 
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2)  Abstract  data  type  example. 

CAPSULE  queues  EXPORTS  queue,  1n1t_queue,  enter,  remove; 
ABBREV. elem  :  INT(0..255>; 

TYPE  queue  (n  :  INT)  :  RECORD!  first, last  :  INT(0  ..  n-1), 

num  :  INTO  ..  n), 

Items  :  ARRAY  INTO  ..  n-1) 
OF  eleml; 

PROC  in1t_queue  (VAR  q  :  queue); 

ASSERT  q.n  >  0; 
q. first  :=  0; 
q.last  :=  0; 
q.num  :=  0; 

END  PROC  1n1t_queue; 

PROC  enter  (VAR  q  :  queue,  r  :  elem); 

ASSERT  q.hurn  <  q.n; 
q.ltems(q.last)  :=  r; 
q.last  :=  (q.last  +  1)  MOD  q.n; 
q.num  :=  q.num  +  1; 

END  PROC  enter; 

PROC  remove  (VAR  q  :  queue,  OUT  r  :  elem); 

ASSERT  q.num  >  0; 
r  :=  q.1tems(q. first); 
q. first  :=  (q. first  ♦  1)  MOD  q.n; 
q.num  :=  q.num  -  1; 

END  PROC  remove; 

END  CAPSULE  queues; 

3)  Exposing  a  definition  makes  the  definition  locally  known  and,  thus,  able  to  be  exported. 

CAPSULE  c  EXPORTS  x; 

VAR  x  ... 

END  CAPSULE  c; 

CAPSULE  b  EXPORTS  x,y;  X  only  locally  known  definitions 

X  can  be  exported. 

VAR  y  ... 

EXPOSE  x  FROM  c;  X  makes  x  locally 

X  known  in  b 

END  CAPSULE  b; 
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Visible  lists  control  the  availability  of  the  definitions  that  are  local  to  the  body  of  a  capsule,  to 
those  scopes  where  the  capsule  is  Invoked.  Visible  lists  appear  in  two  places: 

a)  After  the  word  EXPORTS  in  the  header  of  a  capsule  declaration.  This  visible  list  exports 
selected  definitions,  which  are  local  to  the  body  of  the  capsule,  to  invocations  of  the  capsule. 

b)  After  the  word  EXPOSE  in  a  capsule  invocation  declaration.  This  visible  list  makes  selected 
definitions  which  were  exported  from  the  invoked  capsule,  known  In  the  scope  where  the 
capsule  invocation  declaration  appears. 


Visible  List  in  a  Capsule  Declaration 


If  ALL  is  specified,  all  definitions  which  are  local  to  the  body  of  the  capsule,  except  goto  label 
definitions,  are  exported. 

If  NONE  is  specified,  no  definitions  are  exported. 


If  a  list  is  specified,  all  definitions  which  are  local  to  the  body  of  the  capsule,  and  whose  names 
appear  in  the  list,  are  exported.  Names  of  goto  labels  may  not  appear.  There  must  be  a  definition, 
local  to  the  body  of  the  capsule,  of  each  name  that  appears  in  the  list.  Tho  name  of  any  variable 
definition  may  be  preceded  by  READONLY ;  in  this  case  the  variable  is  treated  as  a  readonly  data  item 
In  those  scopes  where  it  is  exposed. 
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Visible  List  in  a  Capsule  Invocation  Declaration 

If  ALL  is  specified,  all  definitions  exported  by  the  invoked  capsule  are  made  known. 

If  NONE  is  specified,  no  definitions  are  made  known. 

If  a  list  Is  specified,  all  definitions  which  were  exported  from  the  invoked  capsule  and  whose 
names  appear  in  the  list  are  made  known.  There  must  be  an  exported  definition  for  each  name  that 
appears  in  the  list.  The  name  of  any  variable  definition  may  be  preceded  by  READONLY',  In  this  case 
the  variable  is  treated  as  a  readonly  data  item  in  the  scope  where  the  capsule  invocation  appears. 

NOTES 


The  capability  of  specifying  ALL  in  a  visible  lit!  makes  il  aaay  to  create  common  data  poola  and  librariaa.  Exporting  no 
dafinitions  is  useful  for  mam  translation  unit*.  Exporting  soma  dafinitions  is  usaful  for  th*  crsation  of  abstract  data  typaa. 

Whan  a  lype  la  mada  visibla,  assignment  and  selection  operations  are  not  automatically  mad#  visible.  However,  ettrlbule  Inquiry 
for  that  type  is  automatically  mada  visible  whan  the  type  is  mada  visible. 

Capsule  formal  psramstars  and  definitions  which  are  available  from  the  enclosing  scope,  may  not  be  exported  since  they  ere  not 
local  to  the  capsule  body. 

Th#  visibla  list  of  the  capsule  Invocation  declaration  provides  a  convenient  method  of  access  control.  For  example,  suppose  the 
capsule  mnth_library  has  bean  defined  as  a  library  of  mathematical  functions.  In  one  scope  only  some  of  the  functions  may  need  to 
be  known.  The  capsule  might  be  invoked  as 

EXPOSE  Integrate,  mean  FROM  math_11brary; 

In  some  other  scope  a  different  sat  of  functions  might  be  needed.  The  invocation  there  might  be 

EXPOSE  sin,  cos  FROM  math_11brary; 
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A  major  design  criterion  for  this  language  is  that  it  contribute  toward  the  reliability  of  the  systems 
that  it  is  used  to  develop.  Toward  this  end,  a  language  facility,  called  exception  handling.  Is  provided 
so  that  a  user  can  gain  control  and  take  appropriate  action  when  a  runtime  error  occurs.  Both 
user-defined  and  language-defined  runtime  errors  can  be  handled  in  this  way. 

There  are  three  parts  to  exception  handling:  the  definition  of  an  exceptional  condition,  called  an 
exception:  the  occurrence,  or  raising,  of  the  exception;  and  the  handling  of  the  raised  exception. 

Exceptions  are  either  language-defined  (see  Appendix  D)  or  defined  by  the  user  in  an  exception 
declaration.  Exception  names  follow  normal  scope  rules.  Exceptions  are  raised  explicitly  by  the 
elaboration  of  a  raise  or  reraise  statement,  language-defined  exceptions  are  also  raised  automatically 
when  an  exceptional  condition  occurs  during  elaboration.  The  handling  of  an  exception  is  achieved  by 
the  guard  statement,  which  allows  the  user  to  gain  control  when  an  exception  is  raised.  The  guard 
statement  consists  of  two  parts:  a  guarded  body  in  which  an  exception  might  be  raised;  and  a  set  of 
handlers  which  can  handle  exceptions  raised  in  the  guarded  body.  Separate  handlers  can  be  provided 
for  specific  exceptions,  and  a  general  handler  can  be  provided  for  all  exceptions  not  handled 
separately.  When  an  exception  having  a  handler  is  raised  in  the  guarded  body,  the  elaboration  of  the 
guarded  body  is  terminated  and  the  body  of  the  handler  is  elaborated.  Elaboration  of  the  guard 
statement  is  completed  when  elaboration  of  the  handler  is  completed. 

Guard  statements  may  be  nested  within  one  another.  When  an  exception  is  raised,  the  guard 
statement  containing  the  guarded  body  in  which  the  exception  is  raised  is  examined  first.  If  i.t  does 
not  contain  a  handler  for  that  exception,  then  enclosing  guard  statements  are  examined  for  the 
appropriate  handler,  starting  with  the  innermost.  The  guard  statement  selected  must  meet  two 
criteria:  it  must  contain  a  handler  for  this  specific  exception;  and  it  must  not  contain  a  deferred 
declaration  which  contains  the  raised  exception. 

If  no  enclosing  guard  statement  is  found  before  an  enclosing  deferred  declaration  is  found,  for  all 
deferred  declarations  except  tasks,  the  search  for  a  handler  for  the  exception  continues  in  the  scope 
containing  the  invocation  of  the  deferred  unit.  In  the  case  of  tasks,  the  task  activation  is  terminated 
and  no  further  searching  occurs. 

If  the  search  for  a  handler  causes  completion  of  elaboration  of  the  scope  in  which  the  exception 
name  is  defined,  the  exception  name  is  changed  to  X_UNHANDLED  and  the  search  for  the  J(_UNHANDLED 
exception  begins. 

It  is  possible,  within  a  handler,  to  reraise  the  exception  which  caused  the  elaboration  of  the 
handler.  This  allows  a  local  action  to  be  taken  before  searching  resumes  for  another  handler  for  the 
same  exception. 

When  efficiency  of  generated  code  is  more  important  than  the  guarantee  of  reliability,  the 
suppress  pragmat  can  be  used  to  suppress  the  raising  of  exceptions  (see  Appendix  B>. 
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9.1  EXCEPTION  NAMES 


Exception  names  are  defined  by  the  exception  declaration. 

RULES 

Each  identifier  is  defined  as  an  exception  in  the  scope  immediately  containing  the  exception 
declaration. 

NOTES 

Exception  namaa  have  the  tame  acope  rule*  aa  alt  other  namet  (»*#  Section  3.5). 

lanfuate-defined  exception*  (tee  Appendix  D)  are  predefined.  No  u**r-writt*n  exception  declaration  ia  needed. 

EXAMPLES 


EXCEPTION  stack_overflow,  stack_underflow; 
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9.2  GUARD  STATEMENT 


A  guard  statement  allows  the  user  to  gain  control  and  take  appropriate  action  when  an  exception 
is  raised. 

RULES 

Each  identifier  between  WHEN  and  =>  must  be  known  as  an  exception.  All  identifiers  In  a  guard 
statement  must  be  distinct. 

Body  i  is  known  as  the  guarded  body  of  the  guard  statement.  Each  body  2  is  a  handler  for  the  list 
of  exceptions  fo!lowing,the  preceding. WHEN.  Body  3  following  ELSE  *>  is  a  handler  for  all  exceptions 
not  otherwise  handled 

Elaboration  of  a  guard  statement  consists  of  elaboration  of  the  guarded  body. 

NOTES 


An  axcapiion  may  only  ba  axplicitly  rafarancad  in  a  turn’d  statement  if  (ha  guard  statement  ia  in  a  scopa  in  which  tha  axeapitort 
nama  ia  known. 

Tha  aomaniic*  for  finding  a  handler  whan  an  axcaptien  ia  raitad  ia  daaerfcad  in  Saefion  9.3. 


EXAMPLE 
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GUARD 

OPENdnfile,  "fllel",  'OLD); 

BY 

WHEN  X..FILENAME  => 

reports  "Bad  name-filel"  ); 

WHEN  X_NOFILE  => 

report(  "Filel  does  not  exist"  ); 

WHEN  X_FILE  => 

report(  "Attempt  to  open  Infile  twice"  ); 

ELSE  => 

report(  "Unknown  error  when  opening  Infile"  ); 

END  GUARD; 

9.3  RAISING  OF  EXCEPTIONS 


The  raise  statement  can  be  used  to  raise  an  exception. 

RULES 

The  identifier  must  be  known  as  an  exception. 

When  an  exception  is  raised,  a  search  is  made  for  the  smallest  enclosing: 

a)  guarded  body  of  a  guard  statement ; 

b)  deferred  declaration ;  or 

c)  body,  in  which  the  exception  is  defined. 

If  the  body  of  a  guard  statement  is  found  and  that  guard  statement  has  a  handler  for  that 
exception  (either  specifically  or  via  an  ELSE  clause),  elaboration  of  the  guarded  body  is  terminated 
and  the  handler  for  that  exception  is  elaborated.  If  the  guard  statement  does  not  have  a  handler  for 
that  exception,  the  elaboration  of  the  guard  statement  is  terminated  and  that  exception  is  reraised  at 
the  place  where  the  guard  statement  appears. 

If  a  deferred  declaration  which  is  not  a  task  declaration  is  found,  the  invocation  of  the  deferred 
declaration  is  terminated  and  the  exception  is  reraised  at  the  point  of  invocation  of  the  deferred  unit. 
If  a  deferred  declaration  is  found  which  is  a  task  declaration ,  the  task  activation  is  terminated. 

If  the  body  is  found  in  which  the  exception  is  defined,  the  X_UNHANDLED  exception  is  raised. 
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An  sxcoption  may  only  be  raieed  whara  ill  nimi  it  known.  Certain  lan|uafa-d«fined  opirilioni  miy  MiM  lanjuata-defined 
exception!. 

Th#  Iranililor  will  iaaue  •  warning  mam;*  if  ii  di«eov«r»  that  an  exception  will  ilwiyi  bi  railed  al  runlim*.  The  Iranalator 
will  produce  •  Hat,  for  each  deferred  decltretlon,  of  exception!  which  could  be  railed  bul  not  handled  when  that  deferred 
declaration  in  invoked.  II  ia  poaaible  to  raiae  the  X_TERMINATE  exception  in  anolher  aelivellon  (ate  Section  10,2). 

EXAMPLES 

1)  Handling  an  exception  raised  in  an  invoked  function. 

FUNC  sqrt  (x  :  FLOAT)  a>  FLOAT; 

ASSERT  x  >=  0.0; 

END  FUNC  sqrt; 

GUARD 

q  :=  sqrt  (r); 

BY 

WHEN  X_ASSERT  =>  q  :=  0.0; 

END  GUARD; 

2>  Given  two  procedures,  actionl  and  action2,  which  both  do  the  same  thing;  first  try  actionl  and, 
if  it  fails,  then  try  action2. 

GUARD 

actionl; 

BY 

ELSE  =>  act1on2; 

END  GUARD; 

3>  Changing  to  a  more  meaningful  exception. 

GUARD 

Insert  (table,  new_entry); 

BY 

WHEN  X_ASSERT  =>  RAISE  table.error; 

END  GUARD; 
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The  reraise  statement  permits  some  action,  such  as  clean-up  or  statistics  gathering,  to  be  taken 
when  an  exception  is  raised,  before  the  exception  propagates  outside  the  guard  statement. 

RULE? 

The  reraise  statement  must  be  contained  in  the  body  of  a  handier  of  a  guard  statement. 

Elaboration  of  the  reraise  statement  is  equivalent  to  elaboration  of 

RAISE  x; 

where  x  is  the  exception  being  handled. 

NOTES 


Sinew  an  exception  must  ba  raiatd  durinf  elaboration  of  a  juarded  body  of  a  guard  stitement  in  ordar  to  ba  handled  by  the 
handler  of  that  guard  statement,  the  reraiamj  of  an  exception  in  a  handler  does  not  cauie  recuraive  elaboration  of  the  tame  handler 
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1>  How  to  do  local  cleanup  when  an  exception  is  raised. 


BEGIN 

OPEN  ( Inf  tie,  "XYZ\  'NEW); 
GUARD 

X  Process  tnflle 


•  •  • 

BY 

ELSE  => 

CLOSE  ( Inf  He,  'DELETE); 

RERAISE; 

END  GUARD; 

CLOSE  < Inf tie,  'SAVE); 

END; 

2)  How  to  retry  an  action  n  times  before  failure  occurs. 

retry  FOR  1  :  INK  1  ..  n)  REPEAT 
GUARD 

action ; 

EXIT  retry;  X  successful  completion 
BY 

ELSE  => 

IF  1  =  n  THEN 
RERAISE; 

END  IF; 

END  GUARD; 

END  REPEAT  retry; 
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10.  MULTITASKING 

The  multitasking  facilities  provide  a  means  for  scheduling  and  synchronizing  multiple  concurrent 
elaborations.  The  basic  unit  of  multitasking  is  a  task,  which  is  defined  by  a  task  declaration.  A  task  is 
invoked  using  the  task  invocation  statement  which  produces  an  activation  of  the  task.  Each  activation 
is  "named"  by  a  unique  activation  variable.  Elaboration  of  task  activations  is  under  the  control  of 
schedulers  which  determine  When  elaboration  of  each  activation  can  proceed. 

Tasks  can  communicate  in  two  basic  ways:  by  message  passing  and  by  the  use  of  shared 
variables.  Message  passing  works  well  for  distributed  systems  and  contributes  to  program  reliability. 
Several  task  activations  can  communicate  via  shared  memory  simply  by  Importing  the  same  variables, 
or  by  passing  these  variables  as  VAR  or  READONLY  parameters.  No  automatic  mutual  exclusion  Is 
provided  for  shared  variables;  this  must  be  accomplished  by  the  user.  The  region  statement  is 
provided  for  this  purpose. 

Clocks  and  delays  are  also  provided,  both  for  real  time  and  for  activation  times. 

Non-busy  multi-way  waiting  is  available  to  wait  for  messages  and  for  delays. 

There  are  two  levels  of  multitasking  facilities 

1)  High-Level  -  These  facilities  will  be  used  for  most  applications.  Included  her©  is  a  priority 
scheduler  (via  ACT  variables),  message  passing  (via  MAILBOXes),  and  mutual  exclusion  (via 
DATA_LOCKs).  These  facilities  are  described  in  this  chapter. 

2)  Low-Level  -  These  facilities  are  provided  to  allow  system  programmers  to  define  new 
schedulers  and  synchronization  schemes  for  applications  where  the  standard  high-level  facilities 
are  not  appropriate.  Once  defined,  these  new  facilities  can  be  used  by  application  programmers 
in  a  manner  that  is  similar  to  that  used  for  the  built-in  high-level  facilities.  Low-level  facilities 
are  described  in  Chapter  14.  Included  there  is  a  detailed  description  of  the  semantics  of  the 
create,  wait,  and  region  statements.  Also  included  is  a  discussion  of  the  LATCH  data  type,  the 
low-level  details  of  the  ACT  priority  scheduler,  and  of  techniques  for  handling  hardware 
interrupts. 
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10.1  TASK  DECLARATION,  TASK  CREATION,  AND  ACTIVATION  VARIABLES 


A  task  declaration  is  similar  to  a  procedure  declaration.  Tasks,  like  procedures,  are  elaborated 
only  when  invoked.  A  task  is  invoked  by  a  task  invocation  statement  which  creates  an  activation  of 
the  task  which  is  elaoorated  concurrently  with  the  elaboration  of  its  invoker.  When  a  task  Is  invoked, 
an  activation  variable  is  specified  as  a  way  of  "naming"  that  activation.  All  activations  are  named.  For 
example, 

TASK  t  <1  :  INI); 


•  •  • 
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ENO  TASK  t; 

VAR  av  :  ACT;  X  an  activation  variable 

•  •  •  . 

CREATE  t<3)  NAMED  av;  X  invokes  t  with  actual  parameter  3 

X  and  associates  activation 
X  variable  av  with  this 
X  activation  of  t 

In  addition  to  "naming"  the  activation,  the  activation  variable  determines  which  scheduler  is  to 
control  the  activation.  The  type  of  the  activation  variable  is  used  in  this  determination.  The  ACT  type 
selects  the  built-in  priority  scheduler  discussed  in  the  next  section.  Other  activation  variable  types 
can  also  be  defined  for  other  kinds  of  user-defined  schedulers  (see  Section  14.5).  For  example,  a  task 
may  be  scheduled  with  a  user-defined  round  robin  scheduler  as  follows. 

TASK  t; 

END  TASK  t; 

VAR  arr  :  RR_ACT ; 

CREATE  t  NAMED  arr; 

An  activation  variable  can  be  either  active  or  inactive.  All  activation  variables  are  initialized  to  be 
inactive.  When  a  task  activation  is  created,  the  activation  variable  which  names  the  activation  is 
changed  from  inactive  to  active.  When  the  activation  is  complete,  the  variable  is  changed  back  to 
Inactive. 

An  activation  having  an  active  activation  variable  ^an  be  either  eligible  to  run  or  waiting.  When  an 
activation  is  created,  it  is  eligible  to  run.  Some  operations  (e.g.,  a  DELAY)  will  cause  an  activation  to 
wait. 

Each  step  in  the  elaboration  of  a  program  is  part  of  some  activation.  When  a  program  is  run,  the 
system  creates  a  single  main  activation  which  elaborates  the  body  of  the  main  capsule.  Any  activation 
can  create  other  activations  by  elaborating  a  task  invocation  statement. 

The  language  ensures  that  an  activation  of  a  task  will  not  run  longer  than  lifetime  of  the  task's 
declaration.  When  the  scope  in  which  a  task  is  declared  is  about  to  be  left,  the  current  activation 
waits  until  all  activations  of  the  task  are  complete. 
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Task  Declaration 


Identifier  1  is  defined  to  be  a  task  in  the  scope  in  which  the  task  declaration  appears.  Identifier  2 
must  be  the  same  as  identifier  1. 

A  task  may  not  have  OUT  formal  parameters. 

The  lifetime  of  a  task  begins  at  the  beginning  of  elaboration  of  the  scope  in  which  it  Is  declared 
and  ends  at  the  end  of  elaboration  of  the  scope  in  which  it  is  declared. 

When  an  activation  is  about  to  leave  the  scope  of  a  task  declaration,\\  waits  for  all  the  activation 
variables  associated  with  activations  of  that  task  to  be  inactive. 

Task  Invocation 

Elaboration  of  a  task  invocation  statement  consists  of 

a)  elaboration  of  the  o duel  parameters', 

b)  binding  of  the  actual  parameters  to  the  formal  parameters  of  the  named  task  (see  Section  7.3); 

c)  preparing  the  activation  variable  to  elaborate  the  body  of  the  task;  and 

d)  changing  the  variable  from  inactive  to  active.  If  the  variable  is  not  Inactive,  then  the 
X__CREATE  exception  is  raised. 

The  lifetime  of  the  activation  variable  in  a  task  invocation  statement  must  be  greater  than  or  equal 
to  the  lifetime  of  the  invoked  task. 

Any  actual  parameters  passed  either  READONLY  or  VAR  must  have  a  iifetimo  grsaief  Un*  Of*  equal 
to  that  of  the  invoked  task. 

MOTES 


A  moro  detailed  doacription  of  lha  aamantici  of  tha  tisk  Invociticn  stitement  can  bo  found  ta  SoetiiK.  iC.5  3 
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10.2  THE  ACT  PRIORITY  SCHEDULER 

There  is  a  built-in  priority  scheduler.  Elaboration  of  all  task  activations  whose  activation  variables 
have  type  ACT  is  controlled  by  this  scheduler.  This  section  discusses  the  high  level  operations  for  the 
ACT  scheduler.  Low  level  ACT  operations  are  discussed  in  Chapter  14.  Techniques  for  defining  other 
schedulers  are  discussed  in  Section  14.5. 

ME 

The  result  of  the  HE  function  is  the  activation  variable  of  the  activation  that  invokes  ME. 

Priorities 

Scheduling  of  task  activations  whose  activation  variables  have  type  ACT  is  determined  based  on 
priorities.  Each  activation  has  a  priority  which  is  an  integer  with  subtype 

INT(0. .255) 

Priority  0  is  the  lowest  priority  <the  priority  least  likely  to  be  scheduled)  and  priority  255  is  the 
highest  priority  (the  priority  most  likely  to  be  scheduled).  The  priority  of  an  activation,  av,  can  be 
obtained  by  invoking  the  function 

PRIORITY  (av) 

\ 

whose  result  is  the  priority  of  av. 

The  priority  of  any  activation,  av,  can  be  set  to  value  n,  by  invoking  the  procedure 
SET_PRIORITY  (av,n); 

The  initial  priority  of  the  main  activation  of  a  program  is  set  by  the  user  when  the  program  is  to 
be  run.  If  no  priority  has  been  explicitly  set,  the  initial  priority  of  other  activations  is  equal  to  the 
current  priority  of  the  creating  activation. 

Exterminate 

Elaboration  of  the  procedure  invocation 
EXTERMINATE  (a); 

will  cause  the  X_TERMINATE  exception  to  be  raised  in  the  activation  currently  associated  with 
activation  variable'  a.  The  invocation'has  no  effect  if  a  is  inactive.  If  a  is  waiting,  then  it  becomes 
eligible  to  run. 

Scheduling  Algorithm 

At  any  time,  there  will  be  some  activations  which  are  eligible  to  be  run.  The  ACT  scheduling 
algorithm  decides  which  of  the  activations  are  to  be  run.  The  langucge  makes  no  assumptions  about 
the  number  of  activations  which  can  be  run  concurrently.  On  some  target  systems,  at  most  one 
activation  will  be  running  while  on  other  systems,  several  activations  can  be  running  concurrently. 

For  the  set  of  activations  which  are  eligible  to  run,  an  activation  with  a  higher  priority  will  bo 
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scheduled  before  an  activation  with  a  lower  priority  and,  for  activations  having  the  same  priority, 
those  activations  which  have  been  eligible  for  the  longest  time  will  be  scheduled  over  the  other 
activations. 

NOTES 


ME,  PRIORITY,  S£T_PRIORITV,  »nd  EXTERMINATE  iri  dttcrfocd  in  d*t»il  ond*r  lh*  ACT  typ«  m  Appendix  C.1B.  Th*  »eh*duling 
algorithm  i*  dcfcrib^d  in  d*t«il  in  Section  14.2. 

EXAMPLES 

1)  Setting  priorities 

TASK  t; 

•  •  • 

IF  Important  THEN 

SET_PRIORITY(  ME,  PRIORITY(ME)  +  10  >; 

ELSE 

SET_PRIORITY(  ME,  10); 

END  IF; 

END  TASK  t; 

VAR  ta  :  ACT; 

SET_PRIORITY{  ta,  10  ); 

CREATE  t  NAMED  ta; 
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10.3  MESSAGE  PASSING  USING  MAILBOX  VARIABLES 

Message  passing  is  done  via  mailboxes.  Activations  can  send  messages  to  a  mailbox,  and  other 
activations  can  then  receive  these  messages  from  the  mailbox.  A  mailbox  is  a  variable  having  a 
mailbox  type.  For  example, 

VAR  m  : .MAILBOX!  STRING[ASCII3<4)  3(3); 

Here,  m  is  a  mailbox  of  size  3  capable  of  holding  messages,  each  having  the  subtype 
STRING!ASCII3(4).  The  size  specifies  that,  at  any  time,  up  to  3  messages  could  have  been  sent  but 
not  yet  received. 

A  mailbox  is  initially  empty  <i.e.  holds  no  messages).  The  SEND  procedure  is  used  to  send  a 
message  to  a  mailbox.  For  example, 

SEND(m, "MES1" ) ; 

sends  the  message  "ME51"  to  mailbox  m.  Additional  messages  can  be  sent  to  m  by  additional  sends, 
for  example, 

SEND(m, "MES2" ) ; 

SEND(m, "MES3" ) ; 

The  RECEIVE  procedure  is  used  to  receive  a  message  from  a  mailbox.  For  example, 

VAR  v  :  STRINGCASCII3  (4); 

RECEIVED,  v); 

will  place  the  next  available  message  from  mailbox  m  into  variable  v.  Messages  are  stored  in  a  mailbox 
in  order  of  arrival  so  that  the  first  message  to  be  received  from  a  mailbox  will  be  the  first  message 
sent  to  the  mailbox.  In  the  above  example  the  value  of  v  after  Invoking  RECEIVE  would  be  "MES1". 

When  a  mailbox  becomes  full,  no  more  messages  can  be  sent.  If  an  attempt  is  made  to  send  a 
message  to  a  full  mailbox,  then  the  sender  will  wait  until  the  mailbox  is  no  longer  full.  If  there  is  more 
than  one  activation  waiting  as  a  result  of  attempting  to  send  a  message  to  a  full  mailbox,  these 
senders  are  queued  in  the  order  in  which  the  sends  were  done.  The  first  sender  will  therefore  be  the 
first  to  complete  the  send.  A  similar  queueing  occurs  when  receives  are  attempted  on  an  empty 
mailbox. 

Mailboxes  with  Size  0 

When  the  size  of  a  mailbox  is  0,  the  sender  can  never  get  ahead  of  the  receiver.  For  example, 

VAR  ml  :  MAILBOX!  STRINGIASCII3(4)  3  (0); 

In  this  case,  the  SEND(ml,  "ABCD")  will  wait  unless  there  is  some  receive  request  outstanding.  In 
this  latter  case,  SEND(ml,  "ABCD")  will  send  the  message  *ABCD"  directly  to  the  requesting 
receiver. 

RULES 


Messages  for  mailboxes  must  have  an  assignable  type. 
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Messages  sent  to  a  mailbox  and  received  from  that  mailbox  are  handled  on  a  first  in  (i.e.,  first  sent 
to  the  mailbox)  first  out  <i.e.,  first  received  from  the  mailbox)  basis.  In  particular,  the  i'th  receive  will 
get  the  message  from  the  i'th  send. 

MOTES 


Th#  SEND  and  RECEIVE  operations  can  alao  be  uaad  aa  waiting  invocation*  in  th#  watt  aitiement  (*••  Section  10.5). 

In  •  typical  program  structure,  each  mailbox  reprgganta  a  aarvice  which  can  have  aeveral  *aerver“  activation*  that  actually  do 
th#  work.  Thi*  atructur#  allow*  fh#  requestor  to  b*  ignorant  of  th#  actual  number  of  activation*  providing  th#  aarvie#,  and  their 
identities. 

Mor#  detail*  about  th#  MAILBOX  type  e*n  be  found  in  Saetion  14.1. 

Th#  MAILBOX  typ#,  along  with  th#  SEND  and  RECEIVE  procedure*  are  deaerfctd  in  detail  m  Appendix  C.l  1. 

EXAMPLES 

1)  Simple  producer-consumer. 

VAR  m  :  MAILBOXLsJ  (5); 

TASK  produce  IMPORTS  m,  Inffle,  READONLY  sdone; 

VAR  data  :  s; 

WHILE  NOT  EOF < inf lie)  REPEAT 
READUnflle,  data); 

SENDfm,  data); 

END  REPEAT; 

SENDfm,  sdone); 

END  TASK  produce; 

TASK  consume  IMPORTS  m,  outflle,  READONLY  sdone; 

VAR  data  :  s; 

WHILE  TRUE  REPEAT 
RECEIVED,  data); 

IF  data  =  sdone  THEN 
RETURN; 

END  IF; 

WRITEfoutf fie,  data); 

END  REPEAT; 

END  TASK  consume; 

VAR  pr,  cs  :  ACT; 

CREATE  produce  NAMED  pr; 

CREATE  consume  NAMED  cs; 
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10.4  CLOCKS  AND  DELAYS 

There  are  two  basic  kinds  of  clocks:  a  single  real-time  clock  and  a  clock  for  each  activation.  The 
real-time  clock  measures  the  elapsed  real-time  since  the  program  began  to  run.  An  activation  clock 
measures  ihe  total  real-time  that  a  particular  activation  has  been  actually  running  since  it  was  created. 
All  times  are  positive  integers  and  are  measured  in  ticks.  Ticks  are  8n  implementation-dependent  unit. 
There  are  standard  integer  configuration  constants 

MILLISECONDS 

SECONDS 

MINUTES 

HOURS 

whose  values  are  the  (closest  integer  to  the)  number  of  ticks  that  occur  in  each  millisecond,  second, 
minute,  and  hour.  The  function 

TIME 

returns  the  value  of  the  real  time  clock  in  ticks.  The  function 
TIME(a) 

returns  the  value  of  the  activation  clock  for  activation  a  in  ticks. 

An  activation  can  be  delayed  for  t  ticks  of  real  time  by  elaborating 

DELAY(t) ; 

An  activation  can  be  delayed  until  the  value  of  the  real  time  clock  is  t  by  elaborating 
DELAY_UNTIL(t> ; 

An  activation  can  be  delayed  until  the  value  of  the  activation  clock  for  activation  a  has  the  value  t  by 
elaborating 

DELAY_UNTIL( t,a) ; 

An  activation  can  be  delayed  until  some  activation  variable  a  becomes  Inactive  by  elaborating 
DELAY_UNTIL_INACTIVE(  a ) ; 

NOTES 

The  TIME,  DELAY,  DELAYJJNTIL,  and  DEL'AY_UNTIL_INACTIVE  procedural  in  diacribid  in  Appendix  C,  Tb*  configuration 
conitintii  MILLISECONDS,  SECONDS,  MINUTES,  and  HOURS  art  daaerkad  in  Section  12.1. 
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1)  Delayminsec  waits  for  i  minutes  plus  j  seconds  of  real  time. 


PROC  delayminsec  <1,J  :  INT); 

DELAY  (1*HINUTES+j*S£C0NDS); 

END  PROC  delayminsec; 

2)  Measuring  the  total  time  in  seconds  spent  in  running  a  procedure  p. 

CAPSULE  c  EXPORTS  p.ptime; 

VAR  total_t1me  :  INT(0. .1000000)  :s  0; 

PROC  p  IMPORTS  total_t1me; 

VAR  enter  :  INT(0. .1000000)  :=  TIME(ME) ; , 


•  •  « 


total_time  :  =  total_t1me  (TIME(ME)  - 

SECONDS; 


enter)  DIV 


ENO  PROC  p; 


ABNORMAL  FUNC  ptlme  =>  INT<0. . 1000000) 
IMPORTS  total_t1me; 

RETURN  tota1_t1me; 

END  FUNC  ptlme; 

END  CAPSULE  c; 

3)  Performing  an  action  every  i  seconds  of  real  time 

VAR  t  :  INT<0. .1000000)  :=  TIME; 

WHILE  TRUE  REPEAT 
action; 

t  ;=  t+1*5EC0NDS 
DELAY.UNTIL  <t); 

END  REPEAT; 

4)  Reusing  an  activation  variable. 

BEGIN 

TASK  t; 

END  TASK  t; 

VAR  a  :  ACT; 

WHILE  NOT  done  REPEAT 
CREATE  t  NAMED  a; 

DELAY_UNTIL_lNACTIVE(a) ; 

END  REPEAT; 

ENO; 
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10.5  WAITING 


The  wait  statement,  like  a  case  statement,  contains  a  sequence  of  when  clauses.  A  wait  statement 
differs  in  that  waiting  invocations  are  specified  instead  of  expressions.  A  wait  statement  permits 
waiting  until  one  of  the  set  of  waiting  invocations  completes  and,  when  it  completes,  elaborating  the 
body  associated  with  that  waiting  invocation. 

The  following  waiting  invocations  are  built-in. 


SEND<m,v) 

RECEIVED, v) 

DELAY(t) 

DELAYJJNTIKt) 

DELAY_UNTIL(t,a) 

OELAY_UNTIL_INACTIVE(a) 
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The  first  two  are  used  to  send  and  receive  messages  from  some  mailbox  (see  Section  10.3).  The  last 
four  are  used  to  cause  delays  (see  Section  1 0.4^Ad3Ttt^Bl  waiting  invocations  can  be  defined  using 
the  low-level  facilities  discussed  in  Sectiory  14.3^  _  Not e^ that  arbitrary  procedure  end  function 
invocations  cannot  be  used  as  waiting  invoca { 

RULES 

Elaboration  of  a  wait  statement  consists  of  examiningThe  waiting  invocations  following  WHEN.  If  at 
least  one  can  complete  immediately,  one  of  those  that  can  complete  is  allowed  to  complete  and  the 
associated  body  is  elaborated.  If  more  than  one  could  complete,  only  one  will  be  allowed  to  complete; 
the  one  that  actually  completes  is  not  defined.  If  no  waiting  invocation  can  complete  immediately, 
the  task  activation  which  elaborated  the  wait  statement  waits  until  one  can  complete. 


For  SEND's  and  RECEIVE's  used  as  waiting  invocations,  if  none  can  complete  immediately,  the 
activation  that  elaborates  the  wait  statement  is  placed  on  the  FIFO  waiting  queue  of  each  of  the 
specified  mailboxes.  When  one  SEND  or  RECEIVE  completes,  the  activation  will  be  removed  from  the 
FIFO  queues  of  the  other  mailboxes. 


If  a  waiting  invocation  is  SEND  (m,v>,  the  mailbox  m  must  have  a  size  which  Is  greater  than  zero; 
otherwise,  X_EMPTY_MAILBOX  is  raised. 


NOTES 


Low  level  details  of  the  lomaniics  of  the  wait  statement  are  deserved  m  Chapter  14. 


EXAMPLES 

%  wait  on  two  mailboxes 
TASK  consumeZ  IMPORTS  m,  ml,  outfile; 
VAR  data  :  s; 

WHILE  TRUE  REPEAT 
WAIT 

WHEN  RECEIVED, data), 

RECEIVE(ml,data)  => 
WRITEtoutfile,  data); 

END  WAIT; 

END  REPEAT; 

END  TASK  consumeZ; 


INTERMETRICS  INC. 


Section  10.6 


139 


10.6  SHARED  VARIABLES 

A  variable  is  said  to  be  shared  if  two  or  more  activations  can  use  it.  Some  cases  of  sharing  are 
considered  to  be  dangerous  sharing.  Dangerous  sharing  occurs  if  two  activations  simultaneously 
modify  the  same  shared  variable  or  if  one  activation  modifies  a  shared  variable  while  some  other 
activation  is  accessing  that  shared  variable.  The  translator  will  Issue  warning  messages  for  those 
cases  where  dangerous  sharing  might  occur. 

When  dangerous  sharing  of  some  shared  variable  is  possible,  the  user  must  ensure  that  the 
activations  that  can  use  that  shared  variable  elaborate  these  uses  in  an  orderly  way.  If  simultaneous 
use  does  occur,  the  effect  (including  the  state  of  the  variable  and  any  value  accessed)  is  not  defined. 
For  a  shared  variable  where  the  user  has  ensured  orderly  access,  there  Is  a  pragmat  available  to 
suppress  the  warning  messages  for  dangerous  sharing  of  that  shared  variable  (see  Appendix  B). 

NOTES 


Lai  al  and  e2  bt  activations  that  »hir»  torn*  vsriablt  v  in  a  dangtrous  way.  Ordarly  aecaaa  can  ba  tnsurad  by  ailhar  of  lha 
following  moans: 

a)  Using  lha  regbn  statement  <o  surround  any  rafarancaa  lo  v  m  at  and  a2  to  that  only  ona  of  ttw  rafarancaa  can  Kappan  af 
ono  lima  (sat  naxt  saciion). 

b)  Synchronizing  al  and  a2  by  uaing  mattagaa  to  lhai  rafarancaa  to  v  will  not  happan  simultanaoualy  (taa  axampla  balow). 


EXAMPLES 

1>  Mutual  exclusion  with  mailboxes. 

VAR  common  :  INT(0  ..  10); 

VAR  m  :  MAILBOX!  INT(0  ..  0)  3(1); 

TASK  tl  IMPORTS  m,  common; 

VAR  local  :  INT(0  ..  10); 

VAR  right  :  INT(0..0); 

RECEIVE (  m,  right  ); 

common  local; 

SEND(  m,  right  ); 

END  TASK  tl; 

TASK  t2  IMPORTS  m,  READONLY  common; 
VAR  local  :  INT(«r  ..  10); 

VAR  right  :  INTO..0); 

RECEIVE (  m,  right  ); 

local  :=  common; 

SEND(  m,  right  ); 

END  TASK  t2; 

VAR  al,  a2  :  ACT; 

CREATE  tl  NAMED  al; 

CREATE  t2  NAMED  a2; 

SENO(  m,  0  ); 
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10.7  REGION  STATEMENT  AND  DATA  LOCK  VARIABLES 


Use  of  the  region  statement  is  one  way  of  ensuring  the  orderly  access  to  a  shared  variable  by 
several  activations.  The  region  statement  is  normally  used  in  conjunction  with  a  data  lock  variable. 
For  example, 

VAR  d  :  DATA_L0CK; 

A  data  lock  variable  has  two  possible  states:  locked  and  unlocked.  Each  data  lock  variable  is 
automatically  initialized  to  have  the  unlocked  state. 

Basically,  the  region  statement  is  elaborated  by  elaborating  its  body.  However,  the  region 
statement  ensures  that  if  several  activations  contain  region  statements ,  each  specifying  the  same  data 
lock  variable,  at  most  one  of  these  activations  will  be  elaborating  the  body  of  its  region  statement.  If 
two  or  more  activations  attempt  to  elaborate  region  statements  specifying  the  same  data  lock  variable 
simultaneously,  then  all  except  one  will  wait  (until  that  one  completes  elaboration  of  its  region 
statement).  If  several  activations  are  waiting  for  region  access  based  on  the  same  data  lock  variable, 
then  access  will  be  granted  on  a  first -come  first -served  basis. 

The  region  statement  can  also  be  defined  to  work  for  variables  with  types  other  than  DATA.J.OCK 
(see  Section  14.4.1). 


INTERMETRICS  INC. 
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Elaboration  of  a  region  statement  consists  of  the  following  steps: 
a>  lock  the  variable ,  wait  if  necessary  until  this  can  be  done; 
b>  elaborate  the  body;  and 
c>  unlock  the  variable. 

Once  the  variable  has  been  locked,  it  is  guaranteed  to  be  unlocked  whenever  the  elaboration  of 
the  body  completes.  The  unlocking  will  happen  whether  the  body  terminates  normally,  raises  an 
exception,  or  does  an  exit,  goto,  or  return. 

NOTES 


THo  DATA_10CK  typ*  i*  d»*crib»d  in  Apptndix  C.  Dt»i*il«d  famtntict  of  th*  region  statement  »nd  way*  for  uslnf  It  with 
vertobfes  oth*r  lh»n  d*t*  lock  varitbla*  tr*  diicuntd  in  Ch«pl»r  14. 


EXAMPLES 

1)  Simple  mutual  exclusion. 

VAR  common  :  INT(0  ..  10); 

VAR  d  :  DATA_LOCK ; 

TASK  tl  IMPORTS  d,  common; 

VAR  local  :  INT<0  ..  10); 

REGION  d  DO 

common  :=  local; 

END  REGION; 

END  TASK  tl; 

TASK  t2  IMPORTS  d,  READONLY  common; 
VAR  local  :  INT(0  ..  10); 

REGION  d  DO 

local  :=  common; 

END  REGION; 

END  TASK  t2; 

VAR  al,  a2  :  ACT; 

CREATE  tl  NAMED  al; 

CREATE  t 2  NAMED  a2; 
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11.  OVERLOADING  AND  GENERICS 

Overloading  is  the  association  of  a  single  name  with  multiple  deferred  units  of  the  same  Kind.  A 
name  could  be  associated  with  several  different  procedures,  for  example,  but  not  with  a  procedure 
and  a  function.  All  deferred  units  associated  with  a  single  overloaded  name  will  normally  perform 
logically  related  computations.  For  example,  the  overloaded  name  ABS  is  associated  both  with  a 
built-in  function  for  finding  the  absolute  value  of  an  integer  and  with  another  built-in  function  for 
finding  the  absolute  value  of  a  floating  point  number. 

Interfaces  are  used  to  match  each  use  of  an  overloaded  name,  during  translation,  to  a  particular 
deferred  unit  associated  with  that  name. 

In  the  simplest  case,  interfaces  depend  only  upon  a  signature  which  includes  the  number,  order, 
and  types  of  a  list  of  parameters.  The  use  of  an  overloaded  name  in  an  invocation  will  be  resolved  to 
the  deferred  unit  which  has  a  matching  signature;  that  is,  the  number,  order,  and  types  for  the  actual 
parameters  are  identical  to  the  number,  order  and  types  for  the  formal  parameters.  For  example, 

BEGIN 

FUNC  iszero  (a  :  INT)  =>  BOOL;  %  Iszero  1 
RETURN  a=0; 

ENO  FUNC  iszero; 

FUNC  Iszero  (a  ;  FLOAT)  =>  BOOL;  X  Iszero  Z 
CONST  delta  :=  1.0E-5; 

RETURN  a  <  delta  AND  a  >  -delta; 

END  FUNC  iszero; 

VAR  1  ;  INT(-10. .10) ; 

VAR  f  ;  FLOAT < 10,-10.0  ..  10.8); 


..iszero  (1)... 
«  • 

.  .iszero  (f ) . . . 


ENO; 


X  Invokes  iszero  1 
X  invokes  iszero  2 


In  addition  to  the  signature,  interfaces  can  depend  upon  a  translation  time  property  list  specified 
by  a  list  enclosed  in  square  brackets  (i.e.,  [...]>.  The  use  of  an  overloaded  name  in  an  Invocation 
will  be  resolved  to  a  deferred  unit  which  has  a  matching  translation  time  property  list.  For  example, 

BEGIN  ' 

FUNC  zero  [INT]  «>  INT<0..0);  X  zero  1 

RETURN  0 ; 

ENO  FUNC  zero; 

FUNC  zero  [FLOAT]  *>  FLOAT<10,0.0  ..  0.0);  X  zero  2 
RETURN  0.0; 

END  FUNC  zero; 

...zero  tlNTJ...  X  invokes  zero  1 
•  •  • 

...zero  [FLOAT]...  X  invokes  zero  2 


END; 
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The  information  which  is  considered  to  be  part  of  the  interface  depends  upon  the  Kind  of  deferred 
unit.  For  types,  the  translation  time  property  list  is  the  entire  interface  (signatures  are  not  part  of 
the  interface  for  types).  For  other  deferred  units,  the  interface  consists  of  both  the  translation  time 
property  list  <if  specified)  and  the  signature. 

There  are  two  kinds  of  overloading:  explicit  overloading  and  generic  overloading.  Explicit 
overloading  occurs  when  several  distinct  definitions  of  a  name  are  written.  Explicit  overloading  can  be 
used  for  any  kind  of  deferred  unit  except  types.  Generic  overloading  occurs  when  a  single  deferred 
declaration  is  replicated  as  a  result  of  its  appearance  within  a  generic  declaration.  Generic 
overloading  can  be  used  for  any  kind  of  deferred  unit. 

NOTES 

Names  associated  with  variables,  constants,  exceptions,  goto  labels,  or  matching  identifiers  can  not 
be  overloaded. 

11.1  INTERFACES 

Interfaces  are  used  to  resolve  each  use  of  an  overloaded  name  to  one  of  the  deferred  units 
associated  with  that  name.  Interfaces  include  signatures  (for  all  deferred  units  except  types)  and 
translation  time  property  lists  (if  specified). 

RULES 

Each  definition  of  a  deferred  unit  has  a  formal  interface.  Each  invocation  of  a  deferred  unit  has  an 
actual  Interface. 

Each  use  of  the  (possibly  overloaded)  name  of  a  deferred  unit  is  resolved  to  the  deferred  unit 
associated  with  the  name  whose  formal  interface  matches  the  actual  interface  of  the  use.  If  there  Is 
no  such  deferred  unit,  the  use  is  in  error. 

A  'efinitions  of  a  name  conflict  unless 

a)  They  are  both  deferred  units  of  the  same  kind,  and 

b)  Their  Interfaces  do  not  match. 

The  interface  of  a  procedure,  function,  task,  abbreviation,  or  capsule  consists  of  a  signature  and,  if 
specified,  the  translation  time  property  list.  The  interface  of  a  capsule  or  type  consists  of  a 
translation' time  property  list  if  any  is  specified. 

Two  interfaces  match  if: 

a)  Both  have  matching  signatures  or  neither  includes  a  signature,  and 

b)  Both  have  matching  translation  time  property  lists  or  neitner  includes  a  translation  time 
property  list. 


INTERMETRICS  INC. 
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Matching  of  interfaces  is  done  during  translation. 

The  scope  rules  (see  Section  3.5)  permit  a  local  definition  to  override  a  conflicting  definition  in  an 
enclosing  scope;  that  is,  one  deferred  declaration  will  override  another  deferred  declaration  in  an 
enclosing  scope  if  they  have  matching  interfaces.  A  local  declaration  of  one  kind  will  override  all 
declarations  of  another  kind  when  all  share  the  same  namo. 


EXAMPLES 

1)  No  signature  and  no  translation  time  property  list 

PROC  p;  ...  END  PROC  p;  X  definition  1 
•  •  ♦ 

p;  X  Invocation  1 

2>  Signature  and  no  translation  time  property  list 


PROC  p  (x  :  INT);  ...  END  PROC  p; 

P  ( 3 ) ; 

3)  Translation  time  property  list  but  no  signature 
PROC  p  [TNT];  ...  END  PROC  p; 


X  definition  2 
X  Invocation  2 

X  definition  3 
X  Invocation  3 


p  t INT3 ; 

4>  Both  a  signature  and  a  translation  time  property  list 

PROC  p  [INT]  (x  ;  INT);  ...  END  PROC  p;  X  definition  4 

p  [INT]  (3);  X  Invocation  4 
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A  signature  is  part  of  the  interface  between  any  deferred  unit  except  a  type  and  its  Invocations. 
Signatures  are  derived  from  the  formal  and  actual  parameter  lists  and  are  not  explicitly  specified. 

RULES 

The  formal  signature  of  a  procedure,  function,  task,  abbreviation,  or  capsule  is  an  ordered  list  of 
the  types  or  subtypes  specified  for  its  formal  parameters.  The  list  Is  empty  if  it  has  no  formal 
parameters. 

The  actual  signature  of  a  procedure,  function,  task,  abbreviation,  or  capsule  invocation  is  an 
ordered  list  of  the  subtypes  of  its  actual  parameters.  If  there  are  no  actual  parameters,  the  list  is 
empty. 

Two  signatures  match  if  their  lists  are  the  same  length  and  each  of  their  elements  match.  Two 
types  match  if  they  are  equal  <see  Section  4.1.5).  Two  subtypes  match  if  they  belong  to  the  same  type. 
A  type  and  a  subtype  match  if  the  subtype  belongs  to  the  type. 

NOTES 


Function  ratult  typo*  or  aubtypoi  arc  not  conikkrad  to  b*  part  of  a  tifnature. 

EXAMPLES 

FUNC  sign  s>  BOOL;  X  sign  1 

RETURN  FALSE; 

END  FUNC  sign; 

FUNC  sign  <1  :  INT)  =>  BOOL;  X  sign  2 
RETURN  1>=0; 

END  FUNC  sign; 

FUNC  sign  <1,J  :  INT)  =>  BOOL;  X  sign  3 
RETURN  1+j  >=  0; 

END  FUNC  sign; 

FUNC  sign  <x  :  FLOAT)  =>  BOOL;  X  sign  4 
RETURN  x>=0 .0 ; 

END  FUNC  sign; 

FUNC  sign  (x.y  :  FLOAT)  =>  BOOL;  X  sign  5 
RETURN  x+y  >s  0.0; 

END  FUNC  sign; 


VAR  cl,  c2,  c3,  c4,  c5  :  BOOL; 

VAR  k, 1  :  INT<-50. .50); 

VAR  q,r  :  FLOATU0,  -50.0  ..  50.0); 


cl 

:=  sign; 

) 

c2 

: =  sign 

(k); 

c3 

;a  sign 

<k,1); 

c4 

:=  sign 

<q>; 

c5 

:=  sign 

(q.r); 

X  invokes  sign  1 
X  Invokes  sign  2 
X  Invokes  sign  3 
X  Invokes  sign  4 
X  Invokes  sign  5 
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1 1.1.2  TRANSLATION  TIME  PROPERTY  LISTS 


A  translation  time  property  list,  if  present,  is  part  of  the  interface  between  a  deferred  unit  and  its 
invocations.  If  a  formal  translation  time  property  list  is  included  In  a  deferred  unit,  each  of  the 


Section  11.1.2 


148 


REDLRM  8  March  1979 


invocations  must  specify  a  matching  actual  translation  time  property  list.  Translation  time  property 
lists  are  always  explicitly  specified. 


RULES 

Each  expression  must  be  manifest  and  must  be  of  a  type  for  which  equality  (-)  is  defined.  Each 
identifier  must  be  the  name  of  a  function,  procedure,  or  task.  Tte  identifier  ma_y  be  followed  by  an 
actual  translation  time  property  list  only  when  it  appears  as-a  property  liTan  actual  generic  property 
list.  Definable  symbols  may  only  appear  in  an  actual  generic  property  list. 

_  1  ■  iWP— 

Two  translation  time  property  lists  match  if  they  have  the  same  number  of  properties  and  if  their 
corresponding  properties  match.  Two  expressions  match  If  their  values  are  equal.  Two  types  match  if 
they  are  equal  (see  Section  4.1.5).  Two  subtypes  match  if  they  belong  to  the  same  type.  A  type  and  a 
subtype  match  if  the  subtype  belongs  to  the  type.  An  identifier  matches  an  actual  property  if  they 
both  refer  to  the  same  procedure,  function,  or  task. 


EXAMPLES 

BEGIN 

FUNC  zero  CINT]  =>  INT<0..0>;  X  zero  1 

RETURN  0; 

END  FUNC  zero; 

FUNC  zero  [FLOAT,  5]  =>  FLOAT<5,0.0  ..  0.0);  X  zero  2 
RETURN  0.0; 

END  FUNC  zero; 

FUNC  zero  [FLOAT,  10]  *>  FLOAT<10,0.0  ••  0 -0> S  X  zero  3 
RETURN  0.0; 

END  FUNC  zero; 

...zero  [INT]...  Xlnvokes  zero  1 

...zero  [FLOAT,  5]...  Xlnvokes  zero  2 
...zero  [FLOAT,  103...  Xlnvokes  zero  3 


END 
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1 1.2  EXPLICIT  OVERLOADING 

Explicit  overloading  occurs  when  there  are  several  distinct  definitions  of  deferred  units  of  the 
same  kind,  each  of  which  has  the  same  name,  but  a  different  interface. 

RULES 

Explicit  overloading  can  be  used  for  any  kind  of  deferred  unit  except  typts. 

EXAMPLES 

BEGIN 

CAPSULE  stackcap  EXPORTS  stack,  Insert,  remove} 

TYPE  stack  :  ; 

PROC  insert  (VAR  s  :  stack,  1  :  INT);  X  Insert  1 

•  *  • 

END  PROC  insert; 

PROC  remove  (VAR  s  :  stack,  OUT  r  :  INT);  X  remove  1 

*  i  « 

END  PROC  remove; 

END  CAPSULE  stackcap; 

CAPSULE  queuecap  EXPORTS  queue,  Insert,  remove; 

TYPE  queue  ;  . . .  ; 

PROC  Insert  (VAR  s  :  queue,  i  :  INT);  X  insert  2 

END  PROC  insert; 

PROC  remove  (VAR  $  :  queue,  OUT  r  :  INT);  X  remove  2 

•  «  • 

END  PROC  remove; 

END  CAPSULE  queuecap; 

EXPOSE  stackcap; 

EXPOSE  queuecap; 

VAR  s  :  stack; 

VAR  q  :  queue; 

VAR  j  :  INTO.  .10); 

Insert  (s,  3);  X  Invokes  insert  1 
*  *  • 

insert  (q,  4);  X  invokes  insert  2 
•  •  * 

remove  (s,  j);  X  invokes  remove  1 
•  *  • 

remove  (q,  j); 

•  •  • 

END; 


X  invokes  remove  2 
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11.3  GENERIC  DECLARATION 


generic 

declaration 


generic 

oarameters 


deferred 

declaration 


Darameters 


identifier 


generic 

constraint 


constraint 


r 

type  generic  constraint 

73 

n 

subtyoe  generic  constraint 

H 

operation  generic  constraint 

H 

75 

H 

value  generic  constraint 

H 
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A  deferred  declaration  can  be  "generalized"  by  placing  it  in  a  generic  declaration  and  by  replacing 
specific  types,  subtypes,  or  procedure  or  function  names  by  references  to  generic  parameters.  For 
example,  a  sort  procedure  which  sorts  arrays  with  integer  components  can  be  easily  generalized  to  a 
generic  sort  procedure  which  will  sort  arrays  with  any  component  type. 

RULES 

The  deferred  declaration  is  called  the  pattern  declaration  and  defines  the  overloaded  name. 

The  interface  of  the  pattern  declaration  must  contain  a  use  of  each  generic  parameter.  The  us* 
can  be 

a)  within  the  formal  translation  time  property  list,  or 
b>  within  in  the  formal  signature,  or 

c>  in  the  generic  constraint  of  some  other  generic  parameter  that  has  a  use  in  the  Interface.  The 
use  cannot  appear  as  a  result  type  or  subtype  of  a  FUNC  operation  constraint. 

iTa  generic  parameter  appears  more  than  once  in  the  formal  interface,  each  of  the  corresponding 
places  in  an  actual  interface  must  resolve  the  generic  parameter  to  the  same  replacement  element. 

The  generic  declaration  is  replaced  during  translation  by  a  set  of  deferred  declarations  called  the 
generated  set. 

Each  deferred  declaration  in  the  generated  set  is  obtained  first  by  copying  the  pattern  declaration 
and  then  substituting  a  specific  replacement  element  for  each  generic  parameter  and  for  each  needs 
list  definition. 

If  the  overloaded  name  is  never  invoked,  then  the  generated  set  is  empty.  Otherwise,  each 
invocation  of  the  overloaded  name  Is  examined.  Each  invocation  of  the  overloaded  name  will  have  an 
actual  interface  which  will  be  used  to  set  a  replacement  element  for  each  generic  parameter.  Needed 
definitions  are  set  to  corresponding  definitions  known  in  the  scope  of  invocation  <see  Section  11.4).  A 
new  copy  of  the  pattern  declaration,  with  replacement  elements  for  its  generic  parameters  and  for 
each  needs  list  definition,  is  added  to  the  generated  set  if  no  equivalent  copy  has  been  added 
previously,  as  a  result  of  examining  some  other  invocation. 

If  a  generic  declaration  is  capable  of  generating  some  deferred  declaration  that  conflicts  with  a 
particular  definition,  then  the  generic  declaration  itself  is  considered  to  conflict  with  that  definition. 
The  conflict  exists  even  though  the  deferred  declaration  is  not  actually  generated. 

NOTES 


A  generic  dedersthn  i«  tn  op«n  *eop*j  ih*  generic  paremelers  tnd  th*  nwd*  fiat  H#mB  tri  ctefiiwd  in  {hi*  Bcop*. 
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1 1.3.1  TYPE  GENERIC  CONSTRAINTS 


A  generic  parameter  with  a  type  generic  constraint  has  replacement  elements  which  are  types. 


RULES 

Any  type  (including  those  not  known  in  the  scope  of  the  generic  declaration)  may  be  a 
replacement  element  for  a  generic  parameter  whose  generic  constraint  is  TYPE. 

Any  type  whose  name  is  Id  and  is  known  in  the  scope  of  the  generic  declaration  can  be  a 
replacement  element  for  a  generic  parameter  whose  generic  constraint  is  TYPE  ( . . . ,  I,  . . . ). 

EXAMPLES 

GENERIC  t  :  TYPE 

PROC  p  (VAR  x  :  t)  ;  ...  END  PROC  p; 

GENERIC  t  :  TYPE 

CAPSULE  cCtl;  ...  END  CAPSULE  c; 

GENERIC  1  :  TYPE  (INT,  ENUM),  t  :  TYPE(INT, FLOAT) 

PROC  q  (x  :  ARRAY  1  OF  t);  ...  END  PROC  q; 
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1 1.3.2  SUBTYPE  GENERIC  CONSTRAINTS 


A  generic  parameter  with  a  subtype  generic  constraint  has  replacement  elements  which  are 
subtypes. 

RULES 

Any  subtype  (including  those  whose  types  are  not  Known  in  the  scope  of  a  generic  declaration  can 
be  used  as  replacement  elements  for  a  generic  parameter  whose  generic  constraint  is  SUBTYPE. 

Any  subtype  of  type  t  may  be  used  as  a  replacement  element  for  a  generic  parameter  whose 
generic  constraint  is  SUBTYPE  ( . . . ,  t, . . . ). 

Any  subtype  whose  type  has  the  name  Id  and  is  Known  in  the  scope  of  the  generic  declaration 
can  be  used  as  a  replacement  element  of  a  generic  parameter  whose  generic  constraint  is 
SUBTYPE(  . . . ,  Id, . . . ). 

If  a  subtype  is  used  in  several  places  within  the  formal  interface,  then  the  actual  interface  must 
specify  the  same  subtype  in  each  of  the  corresponding  places.  Otherwise,  the  X_SUBTYPE  exception  Is 
raised  when  the  invocation  is  elaborated. 

NOTES 


For  tnterfaca  matehinf,  only  tha  type  of  subtypes  it  uaad  Subtypa  information  ia  uaad  to  oat  generic  peremeters  with  • 
subtype  generic  constrslnt,  it  wall  ••  to  ehaeh  for  conaiataney  of  subtypes  (X_SUBTVPE  thoekinf). 


154 

EXAMPLES 


Section  11.3.2 


REDLRM  8  March  1979 


%  x  and  y  have  the  same  type,  but  not  necessarily  the  same  subtype 
GENERIC  t  :  TYPE 

PROC  p  (VAR  x  :  t,  VAR  y  :  t);  ...  END  PROC  p; 

%  x  and  y  have  the  same  subtype,  which  can  be  referred  to  es  s 
%  within  the  body 
GENERIC  s  :  SUBTYPE 

PROC  p  (VAR  x  :  s,  VAR  y  :  s>;  ...  END  PROC  p; 

%  x  and  y  have  the  same  type  but  not  necessarily  the  same  subtype. 

%  the  subtype  of  x  can  be  referenced  as  si  while  the  subtype 

%  of  y  can  be  referenced  as  s2 

GENERIC  t  :  TYPE,  si  :  SUBTYPE(t),  s2  :  SUBTYPE(t) 

PROC  p  (VAR  x  :  si,  VAR  y  :  s2>;  ...  END  PROC  p; 

GENERIC  si  :  SUBTYPE  (ENUM),  s2  :  SUBTYPE  (ENUM) 

FUNC  f  (a  :  ARRAY  si  OF  s2,  READONLY  b  :  s2)  =>  si;  . . .  END  FUNC  f; 

GENERIC  s  :  SUBTYPE  (ENUM) 

TYPE  vstrlng  [s]  :  PTR  (n  :INT)  STRING  [s]  (n); 
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1 1.3.3  OPERATION  GENERIC  CONSTRAINTS 


An  operation  generic  constraint  has  replacement  elements  which  are  either  procedures,  functions, 
or  tasks.  In  each  case,  the  types  or  subtypes  of  the  formal  parameters  are  specified  and,  for  functions, 
the  result  type  or  subtype  is  also  specified. 


The  replacement  elements  for  the  PROC  generic  constraint  8re  all  procedures  having  the  specified 
number  of  parameters  of  the  specified  types. 

The  replacement  elements  for  the  FUNC  generic  constraint  are  all  functions  having  the  specified 
number  of  parameters  of  the  specified  types  and  the  specified  result  type. 

The  replacement  elements  for  the  TASK  generic  constraint  are  all  tasks  having  the  specified 
number  of  parameters  of  the  specified  typos. 

If  a  parameter  subtype  is  specified,  matching  depends  only  upon  the  type  to  which  it  belongs.  If 
the  subtype  parameter  or  result  specified  in  the  generic  constraint  does  not  match  the  actual  subtype 
of  the  replacement  element,  the  X.SUBTYPE  exception  is  raised. 

If  the  replacement  element  is  itself  overloaded  or  generic,  then  it  is  resolved  in  the  calling  scope 
and  its  needed  items  are  bound  there. 
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GENERIC  f  :  FUNC! FLOAT)  =>  FLOAT 

FUNC  Integrate  tf 3  (low.hlgh  :  FLOAT) 

=>  FLOAT! 20,  -10E10  ..1.0E10); 
CONST  delta  :=  1.0E-5; 

VAR  r  :  FLOAT! 20,  -10E10  ..  1.0E10)  0.0; 

VAR  index  :  FLOAT!  10,  -1.0E10  ..  1.0E10)  :«*  low; 
WHILE  index  <  high  REPEAT 
r  :=  r  +  delta  *  flindex); 
index  index  ♦  delta; 

END  REPEAT; 

RETURN  r; 

END  FUNC  integrate; 


GENERIC  t  :  TYPE,  less_than  :  FUNC!t,t)*>BOOL 
NEEDS  :=(t  t)* 

PROC  sort  tiess_than]  !VAR  a  :  ARRAY  INT  OF  t ) ; 
CONST  min  :=  INDEXOF(a) .MIN; 

CONST  max  :=  INDEXOF(a) .MAX; 

FOR  i  :  INT! 1 . .max-mtn)  REPEAT 

FOR  J  :  REVERSE  INT!max-1 . .max-1 )  REPEAT 
IF  less_than!a!j),  a!j+D)  THEN 
CONST  temp  :=  a(i); 
a(1)  :=  a(1+l); 
a(i+l)  :s  temp; 

END  IF; 

END  REPEAT; 

END  REPEAT; 

END  PROC  sort; 


ABBREV  r  :  RECORD[p,q,s  :  INT!0 . . 100)] ; 
VAR  a  :  ARRAY  INT!  1..  100)  OF  INT(0..100); 
VAR  b  :  ARRAY  INTO.. 500)  OF  r; 


SORT[<]  !a);  X  sort  in  ascending  order 

SORTO]  !a);  X  sort  in  descending  order 


SORTCp'3 -(b) ;  X  sort. ascending  based  on  field  p 

SORTCpq]  !b);  X  sort  ascending  on  primary  key  p 

X  and  descending  on  secondary  key  q 


FUNC  p  (x,y  :  r)  =>  BOOL; 

RETURN  x.p  <  y.p; 

END  FUNC  p; 


FUNC  pq  (x,y  : 
CASE  TRUE 
WHEN  x.p 
WHEN  x.p 
WHEN  x.p 
END  CASE; 
END  FUNC  pq; 


r)  =>  BOOL; 

<  y.p  =>  RETURN  TRUE; 

=  y.p  =>  RETURN  x.q  >  y.q; 
>  y.p  =>  RETURN  FALSE; 
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i  1.3.4  VALUE  GENERIC  CONSTRAINTS 


A  generic  parameter  with  a  value  generic  constraint  has  replacement  elements  which  are  manifest 
values. 

RULES 

A  generic  parameter  with  a  value  generic  constraint  must  appear  as  an  Item  in  a  formal  translation 
time  property  list  within  the  interface. 

The  only  types  and  subtypes  permitted  are  BOOL,  INT,  FLOAT,  ENUM,  and  STRING  types  and 
subtypes. 

For  the  STRING  and  ENUH  constraints,  uses  of  tha  formal  generic  parameter  with  the  pattern 
declaration  are  type  unresolved,  if  the  replacement  element  is  type  unresolved.  For  the  INT,  FLOAT, 
ENUMt...],  and  STRINGtfc]  constraints,  uses  of  the  formal  generic  parameter  within  the  pattern 
declaration  are  subtype  unresolved,  if  the  replacement  element  is  subtype  unresolved. 
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CAPSULE  fcap  EXPORTS  float,  :=,  *,  •••» 


GENERIC  1  :  INTO. .30) 

TYPE  float  Cl]  (a,b  :  FLOAT)  :  FLOAT  (i,  a..b), 

GENERIC  1  :  INTO.. 30) 

FUNC  +  <x,y  :  float  CO)  float  CiJ; 

CONST  r  :=  x.ALL  ♦  y.ALL; 

VAR  z  :s  floatCO  <r..r); 
z. ALL  :=  r; 

RETURN  z; 

END  FUNC  +; 

•  •  • 

END  CAPSULE  fcap; 
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11.4  NEEDS  LIST 


Whenever  a  generic  parameter  is  a  type,  it  is  possible  that  the  pattern  declaration  inside  the 
generic  declaration  requires  some  procedures,  functions  or  tasks  that  operate  on  variables  or 
constants  of  that  type.  Such  procedures,  functions  and  tasks  must  be  obtained  from  the  scope  in 
which  the  overloaded  name  is  invoked,  since  nothing  is  known  about  the  type  In  the  scope  where  the 
generic  declaration  appears.  Such  procedures,  functions  and  tasks  could  be  obtained  by  having 
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additional  generic  parameters,  but  this  would  lead  to  a  proliferation  of  such  parameters.  Instead,  the 
needs  list  provides  this  mechanism.  The  definitions  that  appear  in  the  needs  list  contain  sufficient 
information  to  identify  the  needed  procedure,  function,  or  task  uniquely,  as  well  as  completely  specify 
its  interface. 

RULES 

When  a  generically  overloaded  name  is  invoked,  and  the  generic  declaration  includes  a  needs  list, 
each  definition  in  the  needs  list  is  resolved  to  the  definition  of  the  same  name  and  matching  interface 
known  in  the  scope  where  the  invocation  appears. 

If  the  needed  definition  is,  itself,  generically  overloaded,  then  it  is  resolved  and  its  needs  list  Is 
also  resolved  in  that  scope. 

The  needs  list  may  not  appear  in  any  generic  declaration  whose  pattern  declaration  is  a  type. 
EXAMPLES 

BEGIN 

GENERIC  t  :  TYPE  NEEDS  :=<t,t) 

PROC  swap  <VAR  a,b  :  t); 

CONST  c  :=  a; 
a  :=  b; 
b  js  c  * 

END  PROC  swap; 

VAR  1 , J  :  INT< 1 . . 10) ; 

VAR  f,g  :  FLOATU0,  1.0  ..  10.0); 

t  •  *  » 

swap  (1,j); 

«  ♦  ♦ 

swap  (f,g); 

end!** 
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12.  MACHINE  DEPENDENT  FACILITIES 

This  chapter  discusses  the  facilities  of  the  language  for  specifying  machine  dependent 
representations  for  types,  specific  locations  for  variables ,  techniques  for  using  code  written  In  other 
languages  (including  assembly  language),  and  configuration  capsules  which  encapsulate 
machine-dependent  information.  Other  machine-dependent  facilities  Include  Interrupts  (see  Section 
14.1.4)  and  low-level  I/O  (see  Section  14.6). 

124  CONFIGURATION  CAPSULES 

A  capsule  with  the  name  "configuration"  is  called  a  configuration  capsule.  A  configuration  capsule 
contains  information  that  is  dependent  upon  the  particular  target  system  on  which  a  program  is  to  be 
run.  Some  of  the  Kinds  of  data  that  can  be  specified  in  a  configuration  capsule  include: 

a)  An  identification  of  the  target  computer  and  operating  system  if  any.  For  example, 

CONST  machine  :  =  "IBM370"; 

CONST  op_sys  :=  "VS1"; 

b)  Information  about  memory.  For  example, 

CONST  mem_s1ze  :=  2**18*bytes;  X  256K  bytes 

CONST  bytes  :=  8;  X  8  bits  per  byte 

CONST  words  :=  4*bytes;  X  4  bytes  per  word 

c>  Information  about  timing  (see  Section  10.4).  For  example, 

CONST  milliseconds  :=  2;  X  2  ticks  per  millisecond 

CONST  seconds  :  =  1000*m1 11 iseconds; 

CONST  minutes  60*seconds; 

CONST  hours  :=  60*m1nutes; 

d)  Information  about  I/O  devices.  For  example, 

CONST  console  :»  15;  X  device  15  Is  the  console 

CONST  tapes  :s  4;  X  there  are  4  tape  drives 

e)  Other  machine-dependent  data  of  interest. 

RULES 

When  a  translation  unit  contains  a  capsule  invocation  declaration  which  specifies  the  capsule  name 
configuration,  the  translator  may  check  the  values  of  various  definitions  exported  (even  if  they  are 
not  made  visible)  by  that  capsule,  to  determine  the  characteristics  of  the  target  system.  For  example, 
a  compiler  that  .is  targeted  for  PDP-11  may  check  that  the  constant  machine  is  defined  to  have  the 
value  "PDP11".  The  information  may  also  be  used,  when  several  translation  units  are  linked  together 
to  form  an  executable  program,  to  verify  that  all  translation  units  have  specified  consistent 
configurations. 
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1)  Definition  of  configuration  capsules; 

CAPSULE  configuration  ["IBM360“3  EXPORTS  ALL; 

CONST  machine  :  =  "IBM360"; 

CONST  words  :=  32;  54  32  bits  per  word 

END  CAPSULE  configuration; 

CAPSULE  configuration  CP0P11"]  EXPORTS  ALL; 

CONST  machine  ;=  "PDP11"; . 

CONST  words  :=  16;  54  16  bits  per  word 

•  •  •  i 

END  CAPSULE  configuration; 

2)  Use  of  configuration  capsules: 

CAPSULE  trans_un1tl  EXPORTS  ...  ; 

EXPOSE  NONE  FROM  EXTERNAL  configuration  t"PDPll"]; 

X  this  expose  is  for  checking  purposes  only, 

54  no  machine-dependent  data  Is  visible 

ENO  CAPSULE  trans.unltl; 

CAPSULE  trans„un1t2  EXPORTS  ...  ; 

EXPOSE  words  FROM  EXTERNAL  configuration  t"PDPll"3; 
X  this  translation  unit  uses  the  machine-dependent 
X  constant,  words 

END  CAPSULE  trans_un1t2; 

CAPSULE  main_trans_un1t  EXPORTS  NONE; 

EXPOSE  NONE  FROM  EXTERNAL  configuration  t"PDPll"3; 
EXPOSE  ALL  FROM  EXTERNAL  trans.unltl; 

EXPOSE  ALL  FROM  EXTERNAL  trans_un1t2; 

•  ♦  • 

END  CAPSULE  ma1n_trans_un1t; 
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A  representation  can  be  specified  when  a  new  type  is  declared  (via  the  typo  declaration).  A 
representation  specifies  the  physical  layout  to  be  used  for  data  items  having  subtypes  of  the  new 
type.  The  layout  is  specified  in  terms  of  the  memory  of  the  target  computer  system. 

RULES 

When  a  representation  is  specified,  the  underlying  type  must  consist  only  of  built-in  types.  Each 
of  the  representational  items  are  described  below.  Note  that  several  different  representational  items 
may  be  specified  for  a  given  underlying  subtype  or  one  of  its  components. 

Bit  Numbering 

The  memory  of  the  target  computer  is  considered  to  be  a  sequence  of  bits.  Suppose  there  are  N 
bits  per  word.  The  high  order  bit  of  the  first  word  is  bit  0.  The  low  order  bit  of  the  first  word  is  bit 
N-l.  The  high  order  bit  of  the  m'th  word  is  bit  m*N.  The  low  order  bit  of  the  m*th  word  Is  bit 
m*N+N-l. 

SIZE 

SIZE  can  be  specified  for  any  underlying  subtype  or  component.  The  expression  must  have  type 
INT  and  be  greater  than  or  equal  to  zero  and  specifies  the  maximum  number  of  bits  to  be  used  to 
represent  the  underlying  subtype  or  its  components.  If  no  size  Is  specified,  a  default 
implementation-dependent  size  is  used. 

ALIGN 

ALIGN  can  only  be  specified  for  the  entire  underlying  subtype  (i.e.,  it  can  not  be  specified  for 
components).  The  form 

ALIGN  (exp) 

specifies  that  the  representation  for  the  underlying  subtype  is  to  start  at  a  bit  that  is  at  any  position 
p  such  that  p  =  0  MOD  exp.  The  form 
ALIGN(expl  OF  exp2) 

specifies  that  the  representation  for  the  underlying  subtype  is  to  start  at  a  bit  that  is  at  any  position 
p  such  that  p  =  expl  MOD  exp2.  The  expressions  must  all  have  type  INT.  The  value  of  expression 
exp2  must  be  greater  than  zero.  The  value  of  expl  must  be  in  the  range  0  ..  exp2-l. 

OFFSET 

OFFSET  can  only  be  specified  for  components  of  records  and  unions.  The  value  of  the  expression 
is  the  number  of  bits  from  the  start  of  the  record  or  union  that  the  component  representation  is  to 
start.  The  expression  must  have  type  INT  and  be  greater  than  or  equal  to  zero.  If  an  offset  is  not 
specified  for  a  record  component,  then  that  component  starts  immediately  after  the  previous 
component.  If  an  offset  is  not  specified  for  a  union  component,  then  that  component  starts 
immediately  after  the  tag.  If  no  offset  is  specified  for  the  first  component  of  a  record,  that  component 
starts  at  the  start  of  the  record.  If  no  offset  is  specified  for  a  union  tag,  the  tag  starts  at  the  start  of 
the  union. 
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This  representational  item  can  only  be  used  for  underlying  subtypes  or  for  components  which 
have  RECORD  types.  A  representation  can  be  specified  for  each  component  of  the  record. 

UNION 

This  representational  item  can  only  be  used  for  underlying  subtypes  or  for  components  which 
have  UNION  types.  A  representation  can  be  specified  for  each  component  of  the  union  and  a 
representation  can  also  be  specified  for  the  special  component  named  TAG. 

ARRAY 

This  representational  item  can  only  be  used  for  underlying  subtypes  or  for  components  which 
have  ARRAY  types.  For  each  index  of  the  array,  either  NORMAL  or  NOBOUNDS  must  be  specified. 
NOBOUNDS  indicates  that  information  used  for  array  subscript  bounds  checking  should  not  be  stored. 


ENUM 

This  item  specifies  that  enumeration  values  are  to  be  represented  as  the  integers  0,1,  . . .,  max. 
Since  this  representation  Is  contiguous,  checking  for  illegal  values  (e.g.,  on  input)  is  greatly  simplified. 

ABSENT 

The  identifiers  must  each  be  names  of  attributes  (i.e.,  formal  parameters)  of  the  type  being 
defined.  Absent  attributes  are  not  represented.  Inquiry  is  not  permitted  for  absent  attributes.’ 

PTR 

This  item  specifies  how  the  storage  for  dynamic  variables  is  to  be  recovered.  This 
representational  item  can  only  be  specified  for  indirect  types.  FREE  indicates  that  storage  will  be 
recovered  only  when  the  FREE  procedure  is  explicitly  invoked  (i.e.,  there  will  not  be  any  garbage 
collection).  If  UNCHECKED  is  specified,  no  representation  will  be  provided  for  information  used  to 
check  for  the  X_FREE  exception  when  FREE  is  invoked  for  these  dynamic  variables. 

Implementation-Dependent  Representation 

The  representational  items  described  here  are  only  a  basic  set  which  will  be  supported  by  all 
implementations.  Each  implementation  may  provide  additional  implementation-dependent 
representational  items. 

Restrictions  on  Representation 

A  data  item  is  said  to  have  an  explicit  representation  if 

a)  it  Is  a  component  (including  the  .ALL  component)  of  a  dat8  item  of  a  user-defined  type  that  has 
a  representational  specification,  or 

b>  it  is  a  component  of  a  data  item  that  has  an  explicit  representation. 

A  data  item  that  has  sn  explicit  representation  may  not  be  bound  to  a  formal  parameter  that  has  a 
VAR  or  READONLY  bind'ng  class.  However,  such  data  items  can  be  used  in  expressions,  in  CONST  or 
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OUT  parameter  positions,  and  as  targets  of  the  built-in  assignment  operators. 
NOTES 


When  •  representation  ii  needed  for  a  union  whtr*  the  teg  i*  not  to  eppeer  explicitly,  tHe  een  be  eehioved  by  using  ■  record 
with  overlapping  field*. 

EXAMPLES 

1)  Record  layout 

TYPE  packet  :  RECOROta  :  INT(0..15), 

b  :  BOOL, 

c  :  ENUME'a,  'b,  *c3, 
d  :  ASCII, 

e  :  FL0ATC5,  -100.0  ..  100,0)3 

REP  SIZE(2*W0RDS),  ALIGN( WORDS ) , 

RECORDta  :  SIZE(4>, 
b  :  SIZE(l), 
c  :  SIZE ( 2 ) , 
d  :  SIZE(8),  0FFSET(8) , 
e  :  SIZE(UWORDS),  OFFSET* 1*W0RDS) 3 ; 


2)  Pointers  and  array  layout 

TYPE  myarray  :  PTR(n  :  INT(0..7>> 

REC0R0C1  :  INK0..7), 

a  :  ARRAY(l..n)  OF  BOOL 
REP  PTR  (FREE  UNCHECKED),  SIZE(2*n+4), 

RECORD! 1  :  SIZE(3), 

a  :  SIZE(2*n+l), 

ARRAY  UNCHECKED  OF  SIZE(1)3; 

PROC  1n1t_myarray  (VAR  m:  myarray,  j:  IHT(0..7)>; 
Y.  m  can  be  pass  VAR,  but  m.i  cannot 
ALLOC  m  PTR(j); 
m.i  :=  j; 

END  PROC  1nit_myarray; 
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Record  with  allocation  time  determined  size  and  with  overlaid  fields 

v  xf  d  is  true',  fields  a  and  f  are  present 
%  If  d  Is  false,  fields  b  and  c  are  present 
%  Fields  d  and  e  are  always  present 


TYPE  myunlontn:  INT): 

RECORD  [a 
b 
c 
d 
e 
f 


ASCII, 

BOOL, 

INT<0..7>, 

BOOL, 

FL0AT(5,  -100-0  •- 
STRING! ASCII! <6)3 


100,0), 


REP  ABSENT(n),  SlZE<n*BYTES>, 

RECORD  Ca  :  SIZE<7>,  OFFSETS), 


SIZE(l),  OFFSET(0), 

SIZE ( 3 > ,  OFFSET(l), 

SIZE(l),  OFFSET<7), 

SIZE(4*BYTES),  OFFSETt 1*BYTES>, 
nPFSFT  ( 5*BYTES )  1 ! 


VAR  x  :  myunion(5); 

VAR  y  :  myunlondl); 

x.b  :=  FALSE; 

x.d  :  =  FALSE;  %  b.c  present;  a,f  absent 
x.e  ;=  0*3; 


y.d  :=  TRUE;  X  b,c  absent;  a,f  present 

y.e  :=  0.3; 
y.f  :=  "ABCDEF" ; 


168 


Section  12.3 


12.3  LOCATIONS 


NtU  LKM  tt  March  13 /y 


RULES 

A  location  specification  can  appear  on  any  variable  declaration.  The  specification 
LOCATION  (el) 

will  cause  the  variable  to  be  stored  at  the  memory  location  which  is  the  value  of  el.  The  expression 
el  must  have  type  INT  and  a  value  greater  than  or  equal  to  zero.  The  specification 

LOCATION  ( INTERRUPT  e2> 

can  only  appear  for  variables  which  have  a  MAILBOX  type  and  causes  that  variable  to  be  associated 
with  hardware  interrupt  e2  (see  Section  14.1.4). 
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EXAMPLE 


%  360  program  status  words 

TYPE  psw:  RECORD! sysmask:  ARRAY  INT(0..7)  OF  BOOL, 

key  :  INT(0..15), 
a,m,w,p  :  BOOL, 

Icode  :  INT<0  ..  2**18-1>, 
ilc,  cc  :  INT(0. .3), 
progmask  :  ARRAY  INT<0..3>  OF  BOOL, 
addr  :  INT(0  ..  2**24-l>] 

REP  SIZE(1*WOROS),  ALIGN! 2*W0RDS), 

RECORD! sysmask  :  SIZE(8),  ARRAY  NOBOUNDS  OF  S2ZE(1>, 

key  :  SIZE(4), 

a,m,w,p  :  SIZE! 1 > , 

Icode  :  SIZE(2*BYTES), 

11c, cc  :  SIZE<2>, 

progmask  :  SIZE(4>,  ARRAY  NOBOUNDS  OF  SIZE(l), 

addr  :  SIZE!3*BYTES>3; 

VAR  ext__old_psw  :  psw  LOCATION  (24*words); 

VAR  svc„o1d_psw  :  psw  LOCATION  (32*words); 

VAR  prog_old_psw  :  psw  LOCATION  (40<words); 


12.4  FOREIGN  CODE 

Foreign  code  <i.e.,  code  written  in  other  languages,  including  assembly  language)  can  be  used  as 
part  of  a  RED  program  if  this  feature  is  supported  by  the  translator.  This  is  achieved  by  converting 
the  code  via  an  appropriate  utility  intc  a  RED  translation  unit.  Information  needed  about  linkage 
conventions,  types,  representation,  etc.,  are  supplied  as  directives  to  the  utility  program.  Once  this 
has  been  done,  this  new  translation  unit  can  be  exposed  by  other  translation  units  written  in  RED  as 
though  they  also  had  been  written  in  RED.  Note,  however,  that  the  translator  may  have  to  handle 
these  translation  units  in  a  somewhat  different  fashion  than  it  would  handle  RED  translation  units. 
Note  also  that  some  translators  may  support  open  (i.e.,  inline)  expansions  of  foreign  code. 
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13.  ADVANCED  DEFINITIONS 

This  chapter  discusses  ways  in  which  special  language  forms  can  be  extended  to  work  for  data 
items  having  user-defined  types.  These  forms  include  infix  and  prefix  operators,  assignment, 
selectors,  and  the  case  and  repeat  statements.  Atso  included  is  a  discussion  of  the  automatically 
Invoked  initialization  and  finalization  operations. 

13,1  DEFINABLE  SYMBOLS 


Definable  symbols  ere  used  to  define  functions  for  special  expression  forms  and  assignment 
procedures. 


RUt-lS 


The  cper..  or  symbols  >,  \=,  >»  are  not  definable  symbols. 


NOTES 


Althoufh  dofinnble  symbol*  t.c  defined  as  functions  tnd  proeodurts,  they  esn  not  be  Invoked  unnj  etsndird  invocation  forme. 
They  ere  Involved  only  when  the  correspond^)  specie)  synticiic  form  is  used. 
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13.2  DEFINITION  OF  OPERATORS  AND  ASSIGNMENT 

Users  can  supply  definitions  for  the  built-in  prefix  and  infix  operator  symbols  and  for  assignment. 
These  definitions  allow  built-in  operators  to  be  extended  to  apply  to  data  items  with  user-defined 
types. 

RULES 

Prefix  Operators 

A  function  with  a  single  formal  parameter  and  the  name  +,  or  NOT  defines  that  prefix  operator 
for  a  right  operand  having  the  type  specified  for  the  formal  parameter.  , 

Infix  Operators 

A  function  with  two  formal  parameters  and  the  name  **,  a,  /,  MOD,  DIV,  4,  ♦,  -,  s,  <,  IN,  AND,  OR, 
or  XOR  defines  that  infix  operator  for  a  left  operand  having  the  type  specified  for  the  first  formal 
parameter  and  a  right  operand  having  the  type  specified  for  the  second  formal  parameter. 

For  the  =,  <,  and  IN  infix  operators,  the  function  result  must  have  subtype  BOOL  For  s  and  <, 
both  formal  parameters  must  have  the  same  type.  ,*  ^ 

Associativity 

The  infix  operators  +,  *,  AND,  OR,  XOR,  and  4  are  assumed  to  be  associative.  The  expression 

a  op  b  op  c 
can  bo  evaluated  as  either 
(a  op  ’  op  c 

or  as 

a  op  (b  op  c) 

where  op  is  one  of  these  infix  operators. 

Equality  and  Ordering 

The  equals  <=>  infix  operator  is  assumed  to  define  an  equivalence  relation.  In  particular,  -  is 
assumed  to  be  reflexive  (i.e.,  a=a  is  true),  symmetric  (i.e.,  a=b  is  equivalent  to  b=a>  and  transitive  (i.e., 
if  a=b  and  b=c,  then  a«c).  The  operators  =  and  <,  taken  together,  are  assumed  to  define  a  partial 
order  (with  a  total  order  as  a  special  case).  In  particular,  <  Is  assumed  to  be  transitive  and  It  Is 
assumed  that,  at  most,  one  of 

a=b  or 
a<b  or 
b<a 


will  be  true. 
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The  other  ordering  infix  operators  </=,  >,  <=,  >=)  cannot  be  explicitly  user-defined.  If  a  is 
defined,  then  /a  is  also  automatically  defined.  If  <  is  defined,  then  >  is  also  automatically  defined.  If 
both  -  and  <  are  defined,  then  <a  and  >=  are  also  automatically  defined.  In  particular, 


Purpose 

Operator 

Definition 

not  equal 

a/=b 

NOT(a=b) 

greater  than 

a>b 

b<a 

less  than  or  equal 

a<=b 

a=b  OR  a<b 

greater  than  or  equal 

a>=b 

a=b  OR  b<a 

Assignment 

A  procedure  with  two  formal  parameters  and  the  name  :=  defines  assignment.  Both  formal 
parameters  must  have  the  same  type.  Ths  first  formal  parameter  corresponds  to  the  left  hand  side 
(i.e.,  the  target)  and  the  second  formal  parameter  corresponds  to  the  right  hand  side  (l.e.,  the  source). 

The  assignmsnt  procedure  is  invoked  for 

a)  the  assignment  statement 

b)  initialization 

c)  CONST  and  OUT  formal  parameters 

d>  constructors 

e)  message  passing  via  mailboxes 

For  assignment,  the  following  assumptions  are  made: 

a)  Any  previous  value  of  the  first  parameter  is  lost 

b)  The  only  value  changed  by  assignment  is  the  value  of  the  first  parameter 

c)  The  value  of  the  first  parameter,  after  assignment,  will  be  equal  <l.e.,  their  values  can  be  used 
interchangeably)  to  the  value  of  the  second  parameter  before  assignment.  In  particular,  for 
types  for  which  both  :=  and  =  are  defined,  after  elaboration  of 

a  :  =  b; 
the  expression 
a  »  b 

will  have  value  true  if  a  and  b  are  non-overlapping.  \)v 
Overriding  Default  Definitions 

For  new  types,  :=  and  =  are  automatically  defined  (see  Sections  4.4.2  and  4.4.3).  These  automatic 
definitions,  will  not  occur  if  the  user  provides  explicit  definitions  of  or  =  local  to  the  same  scope  in 
which  the  type  declaration  is  local. 


i/4  ■ 


Section  1372 


RED  LRM  8  March  1979 


NOTES 


Sine®  CONST  and  OUT  bindinj  dtpand  upon  :■>,  (h®  dafmilion  of  :*  should  not  us*  that®  blndinf  class**  (If  it  did,  infinit® 
recursion  would  rasult). 

EXAMPLES 

1)  Integer  sets  via  linked  lists  and  sharing(default)  assignment 

CAPSULE  Intsets  EXPORTS  Intset,  :=,  =  ,  <,  emptyintset, 
and,  or,  xor.  In,  insert; 

TYPE  Intset  :  PTR( 1  :  INT>  RECORDtval  :  INT(1..i>, 

next  :  intset]; 

%  Intsets  are  immutable  sets  of  Integers. 

%  Since  the  list  cells  are  not  modified, 

%  assignment  can  share  these  cells. 

%  Default  :=  is  used 

FUNC  Insert  (1  :  INT,  set  :  intset)  s>  intset; 

VAR  newset  :  Intset; 

IF  set  =  NIL  OR  set.val  >  i  THEN 
ALLOC  newset  PTR(1>  := 

Cval  :  i,  next  :  set]; 

ELSE  IF  set.val  =  i  THEN 
newset  :=  set; 

ELSE 

ALLOC  newset  PTR( set.val)  := 

Cval  :  set.val, 
next  :  Insert! 1,  set. next)]; 

END  IF; 

RETURN  newset; 

END  FUNC  insert; 

FUNC  in  (i  :  int,  set  :  intset)  =>  BOOL; 

IF  set  =  NIL  OR  set.val  >  i  THEN 
RETURN  FALSE; 

ELSE  IF  set.val  =  i  THEN 
RETURN  TRUE; 

ELSE 

RETURN  in  (1,  set. next); 

END  IF; 

.  END  FUNC  in; 


%  —  other  funcs  are  similar  — 


END  CAPSULE  intsets 
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2>  Integer  sets  via  linked  lists  and  copying  (user-defined)  assignment 


CAPSULE  mutable_1ntsets  EXPORTS  intset,  *,  <« 
emptyintset,  and,  or,  xor,  In,  Insert; 

TYPE  tntset  :  Inti  1st; 

TYPE  tntllst  ;  PTR<1  :  INT)  RECORDtval  :  INT( 1 . . 1 ), 

next  ;  Intset]; 

X  Intsets  are  mutable  sets  of  integers. 

X  Assignment  must  copy  the  list  of  cells. 

PROC  (VAR  target  :  intset,  READONLY  source  :  intset); 
IF  source. ALL  =  NIL  THEN 
target. ALL  :=  NIL; 

ELSE 

VAR  newcell  :  intlist; 

ALLOC  newcell  PTR(source.val )  :=  source. ALL; 

X  Note  recursion  In  assigning  the 
X  .next  component  of  source. ALL 
target. ALL  :=  newcell; 

END  IF; 

END  PROC  :=  ; 


PROC  Insert  (1  :  INT,  VAR  set  :  Intset); 
IF  set. ALL  =  NIL  OR  set.val  >  1  THEN 
VAR  old  :  intlist  :=  set. ALL; 
ALLOC  set. ALL  ptr(i); 
set.val  :*  i; 
set. next. ALL  ::  old; 

ELSE  IF  set.val  =  1  THEN 
ELSE 

Insert  (i,  set. next); 

END  IF; 

END  PROC  insert; 

END  CAPSULE  mutable_1ntsets; 
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13.3  INITIALIZATION  AND  FINALIZATION 

When  a  new  type  is  defined,  it  is  possible  to  specify  actions  to  be  taken  at  the  beginning  and  end 
of  the  lifetime  of  each  new  data  item  of  that  type. 

31JLES 

When  a  new  type  is  defined,  the  user  may  also  define  the  procedures  INITIALIZE  and  FINALIZE 
local  to  the  same  scope  as  the  type  definition.  These  procedures  must  each  have  a  single  formal 
parameter  of  the  new  type. 

When  a  data  item  of  the  new  type  is  created,  INITIALIZE  is  automatically  invoked.  This 
invocation  occurs  prior  to  any  explicitly  specified  initialization,  but  after  the  creation  (and 
initialization)  of  the  underlying  variable  or  constant. 

The  created  data  item  (which  is  considered  to  be  variable  during  this  invocation)  is  passed  as  the 
actual  parameter. 

Just  before  the  end  of  the  lifetime  of  a  data  item  of  the  new  type,  FINALIZE  is  automatically 
invoked.  The  data  item  is  passed  as  the  actual  parameter. 

If  the  new  type  is  defined  within  a  capsule,  then  INITIALIZE  and  FINALIZE  need  not  be 
exported  (they  must  be  exported  only  if  they  are  to  be  explicitly  invoked  outside  the  capsule). 

INITIALIZE  and  FINALIZE  are  not  automatically  called  for  VAR  and  READONLY  formal  parameters 
since  these  are  not  new  variables  or  constants,  but  rather  references  to  existing  variables  or 
constants. 

NOTES 


Not*  that  INITIALIZE  and  FINALIZE  thould  not  hava  CONST  or  OUT  paramatara  (if  thoy  do,  an  infiniia  racuraion  will  occur). 
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CAPSULE  stack_cap  EXPORTS  stack,  push,  pop; 

ABBREV  elem  :•  . . .  ; 

TYPE  list  =  PTR  RECORDIval  :  elem, 

next  *  list]* 

TYPE,  stackC size  :  INT)  :  RECORDCcnt’  :  INT(0. .size), 

f  1  4  ^  1  • 

PROC  Initialize  (VAR  s  :  stack); 

s.cnt  :=  8; 

END  PROC  Initialize; 

PROC  push  (VAR  s  :  stack,  e  :  elem); 

ASSERT  s.cnt  <  s.slze; 
s.cnt  :=  s.cnt+1; 

ALLOC  s. first  PTR  :s  tval  :  e,  next  :  s. first]; 

END  PROC  push; 

ABNORMAL  FUNC  pop  (VAR  s  :  stack)  =>  elem; 

ASSERT  s.cnt  >  0; 

CONST  e  :=  s. first. val; 

CONST  n  :=  s. first. next; 

FREE  (s. first); 
s. first  :=  n; 

RETURN  e; 

END  FUNC  pop; 

PROC  finalize  (READONLY  s  :  stack); 

WHILE  s. first  /=  NIL  REPEAT 
CONST  t  :=  s. first; 
s. first  :=  s. first. next; 

FREE  (t); 

END  REPEAT; 

END  PROC  finalize; 


END  CAPSULE  stack_cap; 
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13.4  DEFINITION  OF  SELECTOR  OPERATIONS 

Users  can  define  selector  operations  (subscripting  and  dot  selection)  for  new  types. 

RULES 

Dot  Selection 

The  dot  selection"  form  } 

primary. Id  ' 

will  invoke  the  function  with  name  .Id 
primary  as  the  only  actual  parameter. 

Subscripting 

The  subscripting  form 

primary (exp) 

will  invoke  Ihe  function  with  name  (*)  and  will  pass  primary  as  the  first  actual  parameter  and  exp 
as  the  second  actual  parameter.  The  subscripting  form 

pr1mary(expl  ..  exp2) 

will  invoke  the  function  with  name  (#..*)  and  will  pass  primary  as  the  first  actual  parameter  and 
expl  and  exp2  as  the  second  and  third  actual  parameters. 

For  multiple  subscripts,  the  name  of  the  function  invoked  will  correspond  to  the  invocation  form. 
For  example 

pr1mary(expl,  exp2  ..  exp3,  exp4  ..  exp5) 

will  involve  the  function  with  name  (*,  *..*).  The  number  of  formal  parameters  of  a 

subscripting  function  must  be  equal  to  one  (for  the  primary)  plus  the  number  of  stars  in  its  name. 


> 


(which  mAy  have  o 


jr ^  a  /(ingle  formal  parameter)  and  will  pass 
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EXAMPLES 

1>  Dot  selection 

CAPSULE  cmplx_cap  EXPORTS  complex,  .re,  im,  .mag,  .ang, 

TYPE  complex  :  RECORDtre,  1m  :  FLOAT! 5,  -100.0  ..  100. 

FUNC  .mag  (c  :  complex)  =>  FLOAT! 5,  -100.0  ..  100.0); 
X  definition  1 

RETURN  SORT  !c.re**2  +  c.1m**2>; 

END  FUNC  .mag; 

FUNC  .ang  !c  :  complex)  =>  FLOAT! 5,  -100.0  ..  180.0); 
X  definition  2 
RETURN  ATAN2  !c.1m,  c.re); 

END  FUNC  .ang; 


END  CAPSULE  cmplx_cap; 

EXPOSE  ALL  FROM  cmplx.cap; 

VAR  c  :  complex; 

•  •  4 

...  c.RE  ... 

...  c .  IM  ... 

...  c.MAG  ... 

...  c.ANG  ... 

2)  Subscripting 

CAPSULE  vec_mat  EXPORTS  scalar,  vector, 

matrix,  !*),  !*,*),  (*..*),  (*..*,  *..*>►' 
READONLY  entire; 

TYPE  scalar  :  FLOAT110,  -1000.0  ..  1000.0); 

TYPE  vector  !1  :  INT)  s  ARRAY  INT(1..1>  OF  scalar; 
TYPE  matrix  <1 , j  :  INT)  :  ARRAY  INTU..1),  IHT!l..j) 

OF  scalar; 

TYPE  entirety  :  INT(0..0); 

VAR  entire  :  entirety; 

FUNC  !*..♦)  (READONLY  vl  :  vector,  a  :  INT,  b  :  INT) 
=>  vector(b-a+l); 

X  definition  I 

X  this  overrides  the  default  definition 
X  of  vector  slicing 
VAR  v2  :  vector!b-a+l ) ; 

FOR  1  :  INT(a,.b)  REPEAT 
CONST  j  :=  1-a+l 
v2!J)  :s  vl!1); 

END  REPEAT; 

RETURN  v2; 

END  FUNC! *..*); 


X  uses  automatic  definition 
X  uses  automatic  definition 
X  uses  definition  1 
X  uses  definition  2 
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FUNC  (*)  (READONLY  m  :  matrix,  a  :  entirety,  b  i  INT) 

=>  vector  (INDEXOF(m.ALL)); 

%  definition  2 

VAR  v  :  vector  (INDEXOF(m.ALL)); 

FOR  1  :  INDEXOF(m.ALL)  REPEAT 
v( 1 )  m(1,  b); 

END  REPEAT; 

RETURN  v; 

END  FUNC  (*); 

FUNC  (*,*)  (READONLY  m  *.  matrix,  a  :  INT, 

b  :  entirety)  =>  vector  (INDEXOF(m.ALL,  2)); 
X  definition  3 

VAR  v  :  vector  (INDEXOF(m.ALL,  2)); 

FOR  1  :  INDEXOF(m.ALL,  2)  REPEAT 
v( 1 )  :=  m(a,  1 ) ; 

END  REPEAT; 

RETURN  v; 

END  FUNC  (*,*>; 

FUNC  (*..*,  *..*)  (READONLY  ml  :  matrix, 

a,b  :  INT,  c,d  :  INT) 

=>  matrix  (b-a+1,  d-c+1); 

%  definition  4 

VAR  m2  :  matrix  (b-a+1,  d-c+1); 

FOR  1  :  INT(a..b)  REPEAT 
CONST  j  :=  1-a+l; 

FOR  k  :  INT(c..d>  REPEAT 
CONST  n  :=  k-c+1; 
m2  (J,n)  :=  ml  (1,k); 

END  REPEAT; 

END  REPEAT; 

RETURN  m2; 

END  FUNC  (*..*,  *..*); 


END  CAPSULE  vec_mat; 

EXPOSE  ALL  FROM  vec.mat; 

VAR  r  =  vector(10)-; 

VAR  m  =  matrlxOB,  10); 
VAR  1 , j,  1  ,k  :  INTU..10); 


. . .  v( 1)  ... 

. . .  v( 1 . . j)  ... 

• . .  m( 1 , j )  ... 

. ..  m(ent1re,1)  ... 
...  m(1, entire)  ... 
...  m( 1 . . j,  k.«n)  ... 


%  scalar  -  default  definition  for  vector 
X  vector  -  definition  1 
X  scalar  -  default  def  for  matrix 
X  vector  -  definition  2 
X  vector  -  definition  3 
X  matrix  -  definition  4 
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13.5  DEFINITION  OF  RESOLUTION 

Users  can  define  the  resolution  form  of  expressions  as  a  way  of  getting  "literals"  and 
"constructors"  for  new  types. 

RULES 

The  resolution  form 
exp  #  t 

where  t  is  a  type  or  a  subtype  is  treated  as  the  invocation  of  the  function  with  name  #  and  with 
translation  time  property  list  ft].  The  expression  exp  is  passed  as  the  only  actual  parameter. 

EXAMPLES 

CAPSULE  mod1nt_cap  EXPORTS  modlnt,  #,  ...  ; 

TYPE  modlnt  (modulo  :  INT)  :  INTO,  .modulo-1); 

GENERIC  s  :  SUBTYPE(modlnt) 

FUNC  #  Cs3  <1  :  INT)  =>  s; 

RETURN  1  MOO  s. modulo; 

END  FUNC  #; 

•  •  • 

END  CAPSULE  mod1nt_cap; 

CAPSULE  cmpx_cap  EXPORTS  complex,  #,  ...  ; 

TYPE  complex  =  RECORDCre,  1m  :  FL0AT(5,  -100.8  ..  100.0)3; 

FUNC  #  [complex]  (1  :  RECORDCre, 1m  :  FLOAT])  *>  complex; 

VAR  j  :  complex; 

j.re  :=  l.re; 
j.lm  :=  1.1m; 

RETURN  j; 

END  FUNC 
« 

FUNC  *  [complex]  (1  :  RECORDCmag,  eng  :  FLOAT])  «>  complex; 

VAR  J  =  complex; 

j.re  :=  l.mag  *  SIN(I.ANG); 

J.lm  l.mag  *  COS(I.ANG); 

RETURN  j; 

END  FUNC  #; 


END  CAPSULE  cmpx_cap; 
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13.6  EXTENDING  THE  CASE  STATEMENT  TO  USER-DEFINED  TYPES 

RULES 

A  case  statement  of  the  form 
CASE  el 

WHEN  e2,  e3..e4  s>  bodyl 
WHEN  e 5  =>  body  2 

END  CASE; 

is  expanded  to 

BEGIN 

CONST  c  :=  el; 

CASE  TRUE 

WHEN  c=el,  e3<=c  AND  c<=e4  =  >  bodyl 
WHEN  c=e5  =>  body2 

END  CASE; 

END; 


NOTES 

A  cast  atatsmont  with  only  singla  velu*  labala  can  b*  u»»d  for  ,rrv  .'or  which  equality  (•)  is  dafintd.  A  csss  etstsmant 
with  rang*  valu*  labals  can  Ira  uaad  far  any  typ*  for  which  oquality  (•)  and  ordering  (<)  ara  dafinad. 
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13.7  EXTENDING  THE  REPEAT  STATEMENT  TO  USER-DEFINED  TYPES 


RULES 

A  repeat  statement  of  the  form 

FOR  1  :  s  REPEAT 
body 

END  REPEAT; 

is  expanded  to 

rep  BEGIN 

VAR  1  :  s  :=  s.HIN; 

IF  1  <=  s.MAX  THEN 
WHILE  TRUE  REPEAT 

body  XI  Is  treated  as  read-only  within 
X  the  body 
IF  1  =  s.MAX  THEN 
EXIT  rep; 

END  IF; 

1  :=  SUCC(  1 ) ; 

END  REPEAT; 

END  IF; 

END  rep; 

A  repeat  statement  of  the  form 

FOR  1  :  REVERSE  s  REPEAT 
body 
END  REPEAT; 

Is  expanded  to 

rep  BEGIN 

VAR  1  :  s  :=  s.MAX 
IF  1  >=  s .MIN  THEN 
WHILE  TRUE  REPEAT 

body  %  1  Is  treated  as  read-only 
X  within  the  body 
IF  1  =  s.MIH  THEN 
EXIT  rap; 

END  IF; 
i  ;s  PRED(I); 

ENO  REPEAT; 

END  IF; 

END  rep; 

NOTES 

Any  v>«er  aflmd  .ubtyp.  for  *hich  .MIN,  .MAX,  <,  ond  SUCC  (or  PRED  for  the  r.vr.o  form)  con  bo  um4  In  tho  for  pha« 
of  o  roposl  atatomont. 
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14.  LOW  LEVEL  FACILITIES 

This  chapter  discusses  low-level  facilities  for  multitasking  and  for  I/O.  It  is  anticipated  that  most 
programmers  will  use  the  high-level  multitasking  facilities  (described  in  chapter  10)  and  the  high-level 
I/O  facilities  (described  in  Appendix  A).  The  law-level  facilities  are  provided  for  system  programmers 
as  tools  for  building  new  high-level  facilities. 

14.1  MORE  ABOUT  MAILBOXES 

Some  of  the  low-level  operations  on  mailboxes  that  were  not  described  In  Section  10.3  are 
described  below.  The  use  of  SEND  and  RECEIVE  as  waiting  invocations  Is  described  in  Section  14.3. 
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14.1.1  AVAILABLE  COUNTS 

If  fn  Is  a  mailbox,  then  the  result  of 
EMPTY_SLOTS  <m) 

is  the  number  of  messages  that  can  be  sent  to  m  without  waiting.  This  value  is  the  number  of  empty 
buffers  in  m  plus  the  number  of  unsatisfied  receive  request?  on  m.  Note  that  the  result  of  Invoking 
EMPTY_SLOTS  can  change  if  messages  are  sent  to  m  or  if  any  of  the  receive  requests  are  revoked. 

If  m  is  a  mailbox,  then  the  result  of 
FULL_SLOTS  (m) 

is  the  number  of  messages  that  can  be  received  from  m  without  waiting.  This  value  Is  the  number  of 
full  buffers  in  m  plus  the  number  of  unsatisfied  send  requests  on  fa  Note  that  the  result  can  change  If 
messages  are  received  from  m  or  if  any  of  the  send  requests  are  revoked. 

EXAMPLES 

CAPSULE  event_cap  EXPORTS  pevent, await, signal ; 

%  This  capsule  defines  pulsed  events.  When  a  pulsed 
%  event  Is  signaled,  all  awaiting  activations  continue. 

TYPE  pevent  :  RECORD!  lock  :  DATA_L0CK, 

queue  :  MAILBOX  tINTO .  .0)3  (0)  ]; 

PROC  signal  (VAR  e  :  pevent); 

REGION  e. lock  DO 

WHILE  EMPTY.SLOTS  (e. queue)  >  0  REPEAT 
SEND  (e. queue, 0); 

END  REPEAT; 

END  REGION; 

END  PROC  signal; 

PROC  await  (VAR  e  :  pevent); 

VAR  t  ;  INTC0..0); 

REGION  e.lock  DO  X  this  ensures  that  awaits  arriving 
END  REGION;  X  after  a  signal  will  not  continue 

RECEIVE  (e. queue, t); 

END  PROC  await; 


END  CAPSULE  event_cap; 
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14.1.2  CONDITIONAL  MESSAGE  PASSING 

If  m  is  a  mailboy,  v  is  a  message,  and  b  is  a  boolean  variable,  then  elaboration  of 

COND_SEND  <m,v,b>; 
is  similar  to  elaboration  of 
SEND  (m,v) 

except  that  when  a  wait  would  have  been  required,  no  send  occurs  and  b  Is  set  to  false.  If  the  send 
can  complete  without  waiting,  then  b  is  set  to  true.  There  is  also  a  conditional  receive  procedure  of 
the  form 

COND_RECEIVE  (m,v,b>; 
with  similar  rules. 

EXAMPLES 

%  Producer-consumer  with  busy  waits. 

VAR  m  :  MAILBOX  ts]  (5); 

TASK  produce  IMPORTS  m; 

VAR  d  :  s; 

> 

BEGIN  X  send  with  busy  wait 
VAR  b  :  BOOL  :=  FALSE; 

WHILE  NOT  b  REPEAT 
COND.SEND  (m,d,b) ; 

END  REPEAT; 

END; 

•  •  • 

END  TASK  produce; 

TASK  consume  IMPORTS  m; 

VAR  d  ;  s; 

•  •  • 

BEGIN  X  receive  with  busy 
VAR  b  :  BOOL  :=  FALSE; 

WHILE  NOT  b  REPEAT 

COND.RECEIVE  <m,d,b>; 

END  REPEAT; 

END; 

•  •  • 

END  TASK  consume; 

VAR  pr,cs  ;  ACT; 

SET.PRIORITY  <pr, 10) ; 

SET_PRIORITY  <cs,20>; 

CREATE  consumer  NAMED  cs; 

CREATE  producer  NAMED  pr; 
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14.1.3  ASSIGNMENT  AND  EQUALITY  OF  MAILBOXES 

Mailboxes  are  implemented  as  indirect  types.  Assignment  for  mailboxes  Is  a  pointer  assignment. 
For  the  assignment 

ml  :=  m2; 

where  ml  and  m2  are  both  mailboxes,  the  message  subtypes  of  both  must  be  the  same;  however  ml 
and  m2  need  not  have  the  same  length.  Equality  returns  true  if  both  mailboxes  have  equal  pointers. 

EXAMPLES 

X  message  passing  with  replys. 

ABBREV  sm  :  ...  ;  X  message  subtype 
ABBREV  sr  :  ...  ;  X  reply  subtype 
ABBREV  packet  :  RECOROt  data  :  sm, 

reply  :  MAILBOX  Csr3  (0)  ]; 

VAR  m  :  MAILBOX  [packet]  (10); 

TASK  sender  (id  :  INT)  IMPORTS  m; 

VAR  vm  :  sm;  X  message  variable 
VAR  vr  :  sr;  X  reply  variable 
VAR  r  :  MAILBOX  [sr]  (1); 

WHILE  TRUE  REPEAT 
...  X  compute  vm 

SEND  (m,  [datarvm,  reply ;r 3 ) ;  X  send  message 
RECEIVE  (r,vr);  X  get  reply 

...  X  use  vr 
END  REPEAT; 

END  TASK  sender; 

TASK  receiver  IMPORTS  m; 

VAR  p  :  packet; 

VAR  vr  :  sr;  X  reply  variable 
WHILE  TRUE  REPEAT 

RECEIVE  (m,p);  X  get  message 

...  %  process  the  message(p.data)  and  compute  the  reply(vr) 

SEND  (p. reply, vr ) ;  X  send  the  reply 
END. REPEAT; 

END  task  receiver; 

VAR  sa  :  ARRAY  INTU..10)  OF  ACT; 

VAR  ra  :  ACT; 

CREATE  receiver  NAMED  ra; 

FOR  1  :  INTU..10)  REPEAT 

CREATE  sender(l)  NAMED  sa(1); 

END  REPEAT; 
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14.1.4  INTERRUPTS 

Hardware  interrupts  are  accessed  via  mailboxes  with  an  INTERRUPT  location.  The  subtype  of  the 
message  associated  with  a  given  interrupt  are  device  and  implementation  dependent.  When  an 
Interrupt  occurs,  associated  data  is  collected  and  sent  as  a  message.  The  interrupt  Is  then  cleared. 

EXAMPLES 

Suppose  a  Keyboard  causes  interrupt  16  every  time  a  character  is  typed.  The  Interrupt  is 
handled  as  follows. 

VAR  m  :  MAILBOX  [ASCII]  (5>  LOCATION  (INTERRUPT  16);  - 

TASK  keyboardjiandler  IMPORTS  m; 

VAR  char  :  ASCII; 

«  t  • 

RECEIVE  (m,char);  X  Get  next  Interrupt 
•  •  • 

END  TASK  keyboard_handIer; 

14.2  MORE  ABOUT  THE  ACT  SCHEDULER 

14.2.1  ACT  VARIABLE  STATES 

Each  ACT  variable  has  a  stale  that  consists  of  three  parts: 

active  -  a  boolean.  Active  is  true  if  the  ACT  variable  is  associated  with  an  activation  that  has  been 
been  created  but  is  not  yet  completed,  and  false  otherwise. 

waiting  -  a  boolean.  Waiting  is  true  if  the  activation  associated  with  the  ACT  variable  Is  currently 
waiting. 

suspended  -  a  boolean.  An  activation  whose  ACT  variable  has  suspended  set  to  true  Is  not  eligible  to 
be  run. 

When  an  ACT  variable  is  created,  active,  waiting,  and  suspended  are  automatically  set  to  false. 

If  a  is  an  act  variable,  then  the  following  functions  produce  the  current  value  of  each  of  the  three 
parts  of  the  state. 

ACTIVE(a) 

WAITIf!G(a) 

SUSPENDED(a) 

When  an  activation  is  associated  with  the  ad  variable,  the  value  of  ACTIVE  is  true. 

The  suspended  boolean  is  explicitly  set  by  the  user  using  the  following  procedures. 

SUSPEND  (a);  X  sets  suspended  for  a  to  true 

UNSUSPEND  (a);  X  sets  suspended  for  a  to  false 
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14.2.2  CRITICAL  AREAS 

Whan  an  activation  is  executing  certain  particularly  critical  areas  of  code  It  Is  desirable  to 

a)  prevent  the  activation  from  being  preempted  by  some  othor  activation  (even  If  that  other 
activation  has  a  higher  priority),  and 

b)  temporarily  ignore  any  EXTERMINATE  invocations  for  the  activation. 

This  can  be  achieved  by  elaborating 

CRITICAL; 

at  the  beginning  of  the  critical  are?,  and  elaborating 
NONCRITICAL; 

at  its  end.  When  an  activation  is  created  it  is  noncrtical.  Invocation  of  CRITICAL  makes  it  critical. 
Invocation  of  NONCRITICAL  make  it  again  noncritical.  Vhen  a  running  activation  is  critical  it  Is  never 
preempted.  When  EXTERMINATE  is  invoked  for  some  critical  activation,  no  action  Is  taken  until  the 
activation  becomes  noncritical;  at  which  time  X_TERMINATE  is  raised. 

NOTES 


An  activation  ahould  ba  critical  only  for  vary  abort  taction*  of  cod*. 

14.2.3  SCHEDULING  ALGORITHM 

This  section  gives  the  scheduling  rules  used  by  the  ACT  scheduler. 

RULES 

An  activation  is  eligible  to  be  run  if 

a)  it  is  active; 

b)  it  is  not  waiting; 

c>  it  is  not  suspended. 

If  a  and  b  are  activations  which  are  both  eligible,  the  priority  of  a  is  higher  than  the  priority  of  b, 
and  b  is  not  critical,  then  a  will  be  running  if  b  is  running. 

If  a  and  b  are  activations  which  are  both  eligible,  both  have  the  same  priority,  a  became  eligible 
before  b,  and  b  is  not  critical,  then  a  will  be  running  if  b  is  running. 

If  an  activation  <s  both  running  and  critical,  then  it  will  continue  to  run  until  It  becomes  noncritical 
or  until  it  waits. 

If  there  are  any  activations  that  are  eligible,  then  at  least  one  of  these  will  be  running. 

If  two  or  more  activations  are  running,  no  assumptions  can  be  made  about  their  relative  speeds. 
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14.3  WAITING 

There  are  two  kinds  of  operations  used  for  the  wait  statement:  synchronizing  operations 
associated  with  waiting  invocations  and  scheduler  operations  that  cause  the  activation  to  wait.  Such 
operations  can  be  defined  to  provide  an  alternative  definition  of  the  wait  jtatemtnt. 

14.3.1  SYNCHRONIZING  OPERATIONS  FOR  WAITING  INVOCATIONS 
RULES 

For  each  kind  of  waiting  invocation  of  the  form 
name(el,e2, . . . ,en) 

the  following  five  operations  must  be  defined. 

a)  name_ST  -  a  subtype.  A  variable  with  this  subtype  is  created  for  every  waiting  invocation  that 
is  examined.  For  example, 

VAR  v  :  name_ST; 

b)  name_REQUEST  (v,el ,e2, . . .  ,en)  -  a  procedure.  This  operation  is  invoked  to  request  that 
the  waiting  invocation  be  enqueued  on  the  appropriate  wait  queue.  This  operation  Is  Invoked 
at  most  once  for  each  waiting  invocation  in  a  wait  statement. 

c>  name_TEST<v,el, e2, . . . ,en)  -  a  boolean  function.  The  result  of  this  function  is  true  If  the 
waiting  invocation  can  be  successfully  completed.  The  name_REQUEST  procedure  will  have 
been  invoked  prior  to  invoking  name_TEST. 

d>  name_COHPLETE<v,el,e2 . en)  -  a  procedure.  Invocation  of  this  operation  completes  the 

waiting  invocation.  It  will  be  invoked  only  after  namo_TEST  has  produced  true. 

e>  nflme_REV0KE(v,el,e2, . .  .,en)  -  a  procedure.  This  operation  Is  invoked  for  every  waiting 
invocation  for  which  name_REQUEST  has  been  invoked.  No  other  operations  for  a  particular 
waiting  invocation  will  be  invoked  after  name_REVOKE. 


192 


Section  14.3.1 


RED  LRM  8  March  1979 


EXAMPLES 

This  example  shows  how  the  MAILBOX  type  could  have  been  defined  if  It  were  not  built-in.  Note 
that  this  definition  has  been  simplified  from  the  built-in  MAILBOX  type  In  three  ways. 

a)  It  does  not  do  all  error  checking. 

b)  It  is  not  particularly  efficient. 

c)  Not  all  operations  are  specified. 

d)  It  does  not  handle  zero-length  mailboxes. 

This  example  assumes  that  a  QUEUECs]  data  type  has  been  previously  defined.  Queues  are 
initially  empty  and  have  the  following  operations:  INSERT,  REMOVE,  FIRST  (gets  first  element  without 
removing  it),  SIZE,  and  DEQUEUE  (removes  a  specified  value  from  the  queue). 

CAPSULE  mailboxes 

EXPORTS  mailbox,  send,  receive,  full_s1ots,  empty_s1ots,  cond_send, 
cond_rece1ve,  send_ST,  send_REQUEST,  send_TEST, 
send_COMPLETE, 

send_REVOKE,  rece1ve_ST,  rece1ve_REQUEST,  rece1ve_TEST, 
rece1ve_COMPLETE,  rece1ve_REV0KE  ; 

TYPE  send_ST  :  INT ( 0 .  -  0 ) ;  X  Note  that  these  are  dummys 

TYPE  rece1ve_ST  :  INT ( 0 . . 0 ) ;  X  In  a  more  efficient 

X  Implementation,  these 
X  would  actually  be 
X  elements  linked  Into 
X  the  mailbox  squeue 
X  and  rqueue. 

GENERIC  s  :  SUBTYPE 

TYPE  MAILBOX  ts]  <len:INT)  : 

RECORD!  lock  :  DATA _L0CK , 
msg  :  QUEUE  [s], 
squeue  :  QUEUE  [send_ST], 
rqueue  :  QUEUE  trece1ve_STJ  ]; 


X  Invariants: 

X  (1)  If  SIZE(m.msg)>0  and  SIZE(m.rqueue)>0 then 
X  FI^STv'm. rqueue)  has  been  sent  a  SYNC_5IGNAL 

X  or  will  call  rece1ve_TEST  before  waiting. 

X  (2)  If  SIZE<m,msg)<m.len  and  SIZE(m.squeue)>0 
X  ,  then  FIRST(m. squeue)  has  been  sent  a  SYNC_SIGNAL 
X  or  will  call  send_TEST  before  waiting. 

GENERIC  t  :  TYPE 

ABNORMAL  FUNC  nmpty_slots  (READONLY  m  :  MAILBOX! 1 3  )  *>  INT; 

RETURN  (m. len-SIZE(m.msg))  ♦  SIZE(m. rqueue) ; 

END  FUNC  empty.slots; 
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GENERIC  t  :  TYPE 

ABNORMAL  FUNC  full_slots  (READONLY  m  :  MAILBOXCtS  )  XMT 
RETURN  SIZE(m.msg)  +  SIZE(m.squeue) ; 

END  FUNC  fu11_slots; 

GENERIC' t  :  TYPE 

PROC  sencLREQUEST  <  READONLY  q  :  send_ST, 

VAR  m  :  MAILBOX  [t], 

READONLY  v  :  t  ); 

REGION  m. lock  DO 

INSERT  (m.squeue.ME) ;  X  needn't  wake  up  self 
END  REGION; 

END  PROC  send.REQUEST: 

GENERIC  t  :  TYPE 

ABNORMAL  FUNC  send_TEST  (  READONLY  q  :  send_ST, 

READONLY  m  :  MAILBOX  Ct3, 
READONLY  v  :  t  > 

=>  BOOL; 

RETURN  FIRST  (m.squeue)=ME  AND 

SIZE  (m.msg)  <  m.len  ; 

END  FUNC  send_TEST ; 

GENERIC  t  :  TYPE  NEEDS  :=<t,t) 

PROC  send_COMPLETE  (  READONLY  q  ;  send_ST, 

VAR  m  ;  MAILBOX  [t], 

READONLY  v  :  t.  ); 

REGION  m. lock  DO 

INSERT  (m.msg.v);  X  may  Invalidate  Invariant  1 
IF  SIZE(m.msg)=l  AND  SIZE(m.rqueue)>0  THEN 
SYNC.SIGNAL  (FIRST(m.rqueue)); 

END  IF; 

END  REGION; 

END  PROC  send_COMPLETE; 

GENERIC  t  :  TYPE 

PROC  send_REVOKE  (  READONLY  q  :  send_ST, 

VAR  m  :  MAILBOX  [t], 

READONLY  v  :  t  >; 

REGION  m.  lock  DO  "" 

.(  DEQUEUE  ,(ffl.sqUeue,/Ti)r,  X  may  disrupt  Invariant  2 
/l  IF  SIZHm.squeue  ISLAND  SIZE(m.msg)<m.len  THEN 

^ - SYNCHJSIGNAL  (FIRST(m.squeue) ) ; 

END  IF; 

END  REGION; 

END  PROC  send.REVOKE; 

GENERIC  t  :  TYPE 

PROC  rece1ve_REQUEST  (  READONLY  q  :  rece1ve_ST, 

VAR  m  :  MAILBOX  £tj, 

READONLY  v  :  t  ) ; 

REGION  m. lock  DO 

INSERT  (m.rqueue.ME); 

END  REGION; 

END  PROC  rece1ve_REQUEST; 
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GENERIC  t  :  TYPE  NEEDS  :=<t  t> 

ABNORMAL  FUNC  recelve^TEST  (  READONLY  q  :  received 

READONLY  m  :  MAILBOX~Et3. 

rptudw  trocr/  READONLY  V  :  t 

RETURN  FIRST(m.rqueue)=M£  AND  0<ST7Ftm  m.n« 

END  FUNC  reeeive_TEST; 

t  :  TYPE  NEEDS 

PROC  rece1ve_C0MPLETE  <  READONLY  q  :  receive  ST 

VAR  m  :  MAILBOX  Ct3, 

REGION  m.  lock  DO  VAR  v  : 

IFMSlL!m‘m<n;V>;i  ,X  may  d1sruPt  ^variant  2 
SYNC  TrJnc;}  AND  0<slzE(m.squeue)  THEN 

cun  Ir  ~S IGNA<-  ( FIRST(m . squeue ) ) ; 
fcNu  IF; 

END  REGION; 

END  PROC  r ece 1 ve_COMPLETE ; 

GENERIC  t  :  TYPE  NEEDS 

PROC  rece1ve_REVOKE  (  READONLY  q  :  receive  ST 

VAR  m  :  MAILBOX  [t],~ 

ocf^rri.i  ,  \  READONLY  v  :  t  )• 

RhR  THM  rr>  1  t  n n  '  t 


)  s>  BOOL; 


REGION  m.  loc\  DO 

l  dequeue  (fc.rmieoe.q),  X  nay  disrupt  invariant  1 

■' sym^S f e2UrU? p rS«??0,  SKE<?-**»><«.  l«T  THEN 

' 5;NC_SIGNAL  (FIRST(m.rqueue) ) ; 

tNu  IF ;  x 

END  REGION;  *  '  .  ^ 

END  PROC  rece1ve_REV0XE; 

GENERIC  t  •  TYPE  NEEDS 

PROC  i  :  <  VAR  m  ‘  MAILBOX  [tj, 

READONLY  v  ;  t  ). 

W*  .  '» 

END  WAIT;end  s>  *  tf,*s  S8nd  not  an  Invocation 

END  PROC  send; 

GENERIC  tl  TYPE  NEEDS  :  =  (t,t) 

PROCf receive  <  VAR  m.  :  MAILBOX  Ct3 

VAR  v  :  t  't. 

WAH\  v 

ENDWWArT;0Ce1V8  <m'V>  /  X  th1s  PGCeivfl  not  an  Invocation 
END  PROC  receive;  ,.x 
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GENERIC  t  :  TYPE  NEEDS  <t,t> 

PROC  contLsend  {  VAR  m  :  MAILBOX  [t], 
READONLY -v  :  t, 

VAR  b  :  BOOL  ); 

VAR  q  :  send_ST ; 
send_REQUEST  <q,m,v); 

IF  send_TEST  (q,m.v)  THEN 
send_COMPLETE  <q,m,v); 
b  :=  TRUE; 

ELSE 

b  :=  FALSE; 

END  IF; 

send_REVOKE  <q,m,v); 

END  PROC  cond_send; 

GENERIC  t  :  TYPE  NEEDS  ::=  (t,t) 

PROC  cond_receive  (  VAR  m  :  MAILBOX  Et3, 

VAR  v  :  t, 

VAR  b  :  BOOL  ); 

VAR  q  :  receive_ST; 
receive_REQUEST  (q,m,v>; 

IF  rece1ve_TEST  <q,m.v>  THEN 
rece1ve_COMPLETE  (q,m,v); 
b  :=  TRUE; 

ELSE 

b  :=  FALSE; 

END  IF; 

receive_REVCXE  (q,m,v); 

'  END  PROC  cond_receive; 

END  CAPSULE  mailboxes; 

14.3.2  ACT  SCHEDULER  OPERATIONS  FOR  WAITING 


There  are  three  ACT  scheduler  operations  for  waiting. 

a)  SYNC_RESET  -  a  procedure.  This  procedure  is  invoked  immediately  before  the  name_TEST 
functions  are  checked.  Its  effect  is  to  override  all  previous  SYNC_SIGNALs 

b>  5YNC_WAIT  -  a  procedure.  This  procedure  is  invoked  after  all  name_TEST  functions  have 
produced  false.  Waiting  occurs  if  SYNC„SIGNAL  has  not  been  invoked  for  this  activation  since 
the  last  time  that  5YNC_RESET"was  invoked. 

c>  SYNC_3IGNAL(a)  -  a  procedure  <where  a  is  a  variable  with  type  ACT).  This  procedure  is 
invoked  to  indicate  that  the  result  of  one  of  the  name_TFrT  operations  of  the  specified 
activations  will  be  different  when  next  invoked.  If  the  6w»,.jiion  is  waiting,  as  a  result  of 
performing  SYNC_WAIT,  it  will  be  awakened. 


NOTES 


Extra  invocations  of  §YNC_SIGNAL  will  not  ctue*  trronsous  b*h*vior  sine*  tt>*  n*»s_TEST  functions  *r*  *|»ln  invoktd  before 
eompbtion  of  sny  wtitinx  Invocation, 
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i  4.3.3  EXPANSION  OF  THE  WAIT  STATEMENT 
The  wait  statement 
WAIT 

XhfU  srj‘-‘:r>-  sen<l<B2.''>  «>  bodyl 

END  VAIT;  (I0*«CON0S>  =>  bod* 

can  be  expanded  to 
BEGIN 

VAR  ql  :  SEND„ST;  ' 

VAR  q 2  :  SEND  ST;  *  *  " 

VAR  q3  :  DELAY  ST: 

VAR  1  :  INT(1..2>; 

SEND.REQUEST  (al.ml.v); 

SEND_R£QUEST  < q&,m2,v>; 

DGLAY_REQUEST  (q3, 10*SECONDS); 

loop  WHILE  TRUE  REPEAT 
SYNC.RESET; 

CASE  TRUE 

WHEN  SEND_TEST  <ql,ml,v>  S> 

SEND_COMPLETE  (ql,ml,v>; 
l  • 5 1 ; 

EXIT  loop; 

WHEN  SEND_TEST  <q2,m2,v>  => 

SEND_CGHPLETE  <ql,m2,v); 
t:*l; 

EXIT  loop; 

WHEL?!!;AI-TEST  ^SECONDS)  b> 

OELAY.COHPLEIE  <q3, 10*SECONDS) ; 

EXIT ' loop ; 

ELSE  => 

SYNC.WAIT; 

END  CASE; 

END  REPEAT  loop; 

SEND_REVOKE  (ql.rni.v); 

SEND_REVOXE  (q2,m 2,v); 

DELAY_REVOKE  <q3, 10*SECONQS) ; 

CASE  1 

WHEN  1  s>  bodyl 
WHEN  2  s>  body2 
END  CASE; 

END; 

%£££  z:::-  . . *°  — .  - 
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14.4  MORE  ABOUT  MUTUAL  EXCLUSION 
14.4.1  SEMANTICS  OF  THE  REGION  STATEMENT 
EULES 

A  region  statement  has  the  form 

REGION  cv.p  DO 
body 

END  REGION: 

and  is  roughly  equivalent  to 

LOCK  (exp); 

GUARD 

body 

BY  ELSE  => 

UNLOCK  (exp); 

RERAISE; 

END  GUARD; 

UNLOCK  (exp); 

Note  that  LOCK  is  invoked  at  entry  to  the  region  and  that  UNLOCK  is  invoked  at  exit  from  the  region 
(even  when  the  exit  occurs  as  the  result  of  an  unhandled  exception).  Recall  however,  that  a  region 
statement  guarantees  that  the  region  will  be  unlocked  no  matter  how  it  is  left.  There  are  two  cases 
where  the  rough  expansion  must  be  further  refined 

a)  Exits  and  gotos  out  of  the  body  of  a  region  must  also  cause  UNLOCK  to  be  invoked. 

b>  If  an  EXTERMINATE  occurs  at  certain  critical  points  (such  as  after  the  LOCK  but  before  the 
GUARD),  unlocking  will  not  occur  in  the  rough  expansion.  This  problem  Is  avoided  by  making 
certain  parts  of  the  expansion  be  run  as  critical,  so  any  exterminates  will  be  deferred.  In 
particular,  invocations  of  LOCK  and  UNLOCK  will  be  run  as  critical,  while  the  elaboration  of  the 
body  will  not  be  critical. 


MPIfiS 


A  variable  v/Hh  any  type  for  which  LOCK  and  UNLOCK  proeadurat  »ra  defined  can  b«  uaad  m  th*  region  statement. 
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EXAMPLES 

This  example  shows  how  monitors  can  be  defined  in  the  language, 
how  monitors  can  be  used. 


CAPSULE  1 1ne_buffer  EXPORTS  send,  receive; 

VAR  lock  :  MONITOR_LOCK ; 

VAR  contents  :  line; 

VAR  full  :  BOOL; 

VAR  sender,  receiver  :  M0NIT0R_QUEUE  (lock); 

PROC  receive  (OUT  text  :  line)  IMPORTS  ALL; 
REGION  lock  DO 

IF  NOT  full  THEN 
DELAY  (receiver); 

END  IF; 

text  :=  contents; 
full  :=  FALSE; 

CONTINUE  (sender); 

END  REGION; 

END  PROC  receive; 

PROC  send  (text  :  line)  IMPORTS  ALL; 

REGION  lock  DO 
IF  full  THEN 

DELAY  (sender); 

END  IF; 

contents  :=  text; 
full  :=  TRUE; 

CONTINUE  (receiver); 

END  REGION; 

END  PROC  send; 
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END  CAPSULE  11ne_buffer; 
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The  two  data  types  needed  for  monitors,  M0NIT0R_L0CK  and  MONITOR_QUEUE,  together  with  their 
operations  are  defined  as  follows. 

CAPSULE  mon1tor_defs  EXPORTS  monltor.lock,  mon1tor_queue, 

lock,  unlock, 

delay,  continue,  :a  ; 

TYPE  mon1tor_lock  :  PTR  RECORDtexternal ,  urgent  :  DATA_LOCK]; 

TYPE  mon1tor_queue  (lock  :  mon1tor_lock)  :  DATA_LOCK; 

PROC  initialize  (VAR  m  :  mon1tor_lock> ; 

ALLOC  m  PTR; 

LOCK  (m. urgent);  X  lock  the  urgent  queue  so  that  the  next 
X  activation  to  lock  will  wait 

END  PROC  Initialize; 

PROC  Initialize  (VAR  mq  :  mon1tor_queue) ; 

LOCK  (mq.ALL);  X  lock  the  monitor  queue  so  that  the  next 

X  activation  to  lock  will  wait 

END  PROC  Initialize; 

PROC  lock  (VAR  m  :  mon1tor_lock) ; 

LOCK  (m. external ) ;  X  lock  the  main  lock 
END  PROC  lock; 

PROC  unlock  (VAR  m  :  mon1tor_lock) ; 

IF  EXCESS_LOCKS  (m. urgent)  >  1  THEN 

UNLOCK  (m. urgent);  X  release  next  activation  from 

X  the  urgent  queue 

ELSE 

UNLOCK  (m. external );  X  unlock  the  main  lock 
END  IF; 

END  PROC  unlock; 

PROC  continue  (VAR  mq  :  mon1tor_queue); 

IF  EXCESS.LOCKS  (mq.ALL)  >  1  THEN 

UNLOCK  (mq.ALL);  X  release  the  next  activation 

X  waiting  on  mq 

LOCK  (mq.lock-.urgent);  X  wait  on  the  urgent  queue 
END  IF; 

END  PROC  continue; 

PROC  delay  (VAR  mq  :  mon1tor_queue) ; 

unlock  (mq.lock);  X  leave  the  region 
LOCK  (mq.ALL);  X  wait  on  the  mq  queue 
END  PROC  delay; 


END  CAPSULE  monltor.defs; 
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14.4.2  MORE  ABOUT  DATALOCKS 

In  addition  to  lock  and  unlock,  data  lock  variables  also  have  operations  EXCESS_LOCKS  and  OWNER. 
If  d  is  a  data  lock  variable,  then  the  result  of 

EXCESS.LOCKS  (d> 

is  the  number  of  times  that  LOCK(d)  has  been  invoked  <but  not  necessarily  completed)  minus  the 
number  of  times  UNLOCK! d)  has  been  called.  The  values  that  result  can  be  Interpreted  as  follows: 

a)  0  -  The  lock  is  unlocked. 

b)  1  -  The  iock  is  locked  and  there  are  no  activations  waiting. 

c)  >1  -  Thera  are  activations  waiting,  attempting  to  lock  the  data  lock. 

If  d  is  a  data  lock  variable,  then  the  result  of 
OWNER  <d) 

is  the  activation  that  locked  the  data  lock  or  NIL_ACT  if  the  data  lock  is  unlocked. 

14.4.3  LATCH 

Latches  are  the  basic  low-level  synchronization  type.  Since  LOCK  and  UNLOCK  procedures  are 
available  for  latches,  they  can  be  used  in  the  region  statement. 

RULES 

Latches  are  either  locked  or  unlocked.  Elaboration  of 
LOCK  (t); 

(where  t  is  a  variable  with  type  LATCH)  will  lock  t  if  t  is  unlocked;  otherwise,  it  will  wait  until  t 
becomes  unlocked.  If  there  are  several  activations  waiting  to  lock  a  latch,  which  one  will  actually 
succeed  when  the  lock  becomes  unlocked  Is  undefined.  Elaboration  of 

UNLOCK  (t) ; 

will  unlock  latch  t.  Elaboration  of 
COND_LOCK  ( t,b) ; 

where  b  is  a  boolean  variable,  will  lock  t  if  t  is  unlocked  and  set  b  to  true;  otherwise,  t  is  not 
changed  and  b  is  set  to  false. 

NOTES 

Tho  only  virtua  of  tatchaa  it  that  thay  hava  an  inaxpanaiva  implamantaiion.  In  mtny  cite*,  th«  waiting  e»n  bo  dono  aa  buoy 
waiting. 
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14.5  USER-DEFINED  SCHEDULERS 

In  addition  to  the  built-in  priority  ACT  schedulers,  users  can  define  their  own  schedulers.  The 
scheduler  to  be  used  for  an  activation  is  determined,  whan  the  activation  Is  created,  by  the  type  of 
the  activation  variable  specified  (after  NAMED)  in  the  task  invocation  statement.  User-defined 
schedulers  are  capsules  that  define  the  type  for  their  activation  variables  and  a  set  of  basic 
scheduling  operations.  The  operations  are  implemented  In  terms  of  Invocation  of  the  fundamental 
operations  of  the  built-in  ACT  scheduler.  Synchronization  schemes  (including  DATA_LOCK  and 
MAILBOXes)  are  designed  in  such  a  way  that  they  will  work  correctly  with  any  scheduler  (l.e.,  they  are 
independent  of  the  particular  scheduler  used). 

14.5.1  ACT  ASSIGNMENT  AND  EQUALITY 

ACT  is  implemented  as  an  indirect  type.  Assignment  for  variables  with  an  ACT  type  is  a  pointer 
assignment.  The  assignment 

al  :=  a2; 

where  al  and  a2  are  both  ACT  variables,  sets  al  to  point  to  the  same  Information  as  a2.  Equality 

returns  true  if  both  variables  point  to  the  same  information.  There  is  also  a  constant,  Nil _ ACT,  wh.’ch 

has  type  ACT  and  is  a  nil  pointer. 

NOTES 


ACT  aaaijnmonl  and  aquality  ara  usaful  for  craaiinf  quouaa  of  act  variables. 
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14.5.2  LOW  AND  HIGH  OPERATIONS 
RULES 

When  an  activation  exists  that  is  controlled  by  a  user-defined  scheduler,  there  are  really  two 
schedulers  involved:  the  user-defined  scheduler  and  the  underlying  ACT  scheduler.  There  are  also 
two  activation  variables  involved,  one  for  each  scheduler.  For  example, 

VAR  ua  :  USER_ACT; 

CREATE  t  NAMED  ua; 

creates  an  activation  of  task  t,  which  is  controlled  by  the  USER„ACT  scheduler.  The  two  activation 
variables  here  are 

a)  ua  —  The  activation  variable  for  the  user-defined  USER_ACT  scheduler. 

b)  Another  variable  of  type  ACT  (which  is  not  explicitly  named,  but  for  reference  purposes  call  it 
aa>.  The  variable  aa  is  the  one  by  which  the  ACT  scheduler  controls  scheduling  of  the 
activation. 

The  result  of  elaborating 
ME 


during  elaboration  of  the  activation  of  t  will  be  aa  and  the  result  of  elaborating 
ME  [USER_ACT] 


during  elaboration  of  the  activation  of  t  will  be  ua.  The  X_SCHED  excepiion  is  raised  If  the  activation 
variable  of  the  invoking  activation  does  not  have  type  USER_ACT.  The  function  ME  is  called  a 
low-level  operation  (accessing  the  underlying  ACT  scheduler  information)  and  the  function  ME 
[USER_ACT]  is  called  a  high-level  operation  (accessing  the  specified  activation  variable  ua). 

Variable  ua  normally  contains  sufficient  information  for  the  USER_ACT  scheduler  to  find  aa 
(actually  the  information  that  aa  points  to).  This  can  be  done  by  including  aa  as  a  component  of  U»> 
or  by  making  ua  an  index  into  some  scheduling  queue  that  contains  aa. 

There  are  also  two  sets  of  scheduling  operations  available:  one  high-level  set  for  the  USER_ACT 
scheduler  and  another  low-level  set  for  the  ACT  scheduler.  The  high-level  USER_ACT  operations  are: 


SYNC_RESET(ua); 
SYNC_WAIT(ua) ; 
SYNC_SIGNAL(ua) ; 
TASK_END(ua>; 


X-used  for  watting 
X  used  for  watting 
X  used  to  end  watting 
X  Invoked  at  the  completion  of  the 
X  activation 


These  all  invoke  procedures  defined  for  the  USERJ\CT  scheduler.  The  low-level  operations  are: 


LOW_SYNC_RESET ; 
LOW_SYNC_WAIT; 
L0W_SYNC_5IGNAL( a ) ; 
LOW_TASK_ENO(  a ) ; 


These  all  invoke  procedures  defined  for  the  ACT  scheduler.  The  high-level  operations  will  normally 
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To  allow  synchronization  schemes  to  be  independent  of  any  particular  scheduler,  there  is  a  way  of 
getting  from  ACT  variable  aa  to  the  high-level  operations  upon  the  USER_ACT  variable  ua.  This  Is 
achieved  by  the  following  ACT  scheduler  operations: 

SYNC_RESET ;  X  Invokes  SYNC.RESET(ua) ; 

SYNC_WAIT;  X  Invokes  SYNC_WAIT(ua) ; 

SYNC_SIGNAL( sa  > ;  X  Invokes  SYNC_SIGNAL(ua) ; 

TASK_END(aa) ;  X  Invokes  TASK.END(ua) ; 

The  way  in  which  these  operations  are  achieved  is  described  in  .  the  next  subsection.  These 
operations  allow  synchronization  operations  to  be  ignorant  of  the  particular  scheduler  that  Is  being 
used.  For  example,  during  the  elaboration  of  the  activation  of  t,  invocation  of 


SYNC_WAIT ; 
will  cause  the  invocation 
SYNC_WAIT(ua) ; 

to  occur.  This  means  that  the  synchronization  operations  need  not  directly  invoke 
SYNC_WAIT(ME[USER_ACT] > ; 

If  this  had  been  necessary,  the  synchronization  operation  would  have  needed  knowledge  of  the  type 
USER_ACT. 

Note  that  when  activations  are  scheduled  by  the  ACT  scheduler  <i.e.,  no  user-defined  scheduler  Is 
Involved),  then  the  following  operations  are  equivalent: 


SYNC_RESET ; 
SYNC.WAIT; 
SYNC_SIGNAL(a) ; 
TASK_END( a ) ; 


X  Is  equivalent  to 
X  is  equivalent  to 
X  is  equivalent  to 
X  is  equivalent  to 


LOW_SYNC_RESET 
LOW-SYNC_WAIT 
LOW_SYNC_SIGNAL( a ) 
LOW_TASK_END(a) 
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14.5.3  TASK  ACTIVATION  CREATION  AND  COMPLETION 
RULES 

TASK  INVOCATION  STATEMENT 

The  task  'invocation  statement  has  the  form 
CREATE  t<el,e2 . en)  NAMED  av; 

The  effect  of  elaborating  this  statement  is 

a)  create  a  new  variable  of  type  ACT  (for  reference  call  it  aa>. 

b)  create  a  new  activation  of  t,  place  information  about  it  (e.g.,  starting  address,  stack  locations, 
save  area,  etc.)  in  aa. 

c)  bind  the  actual  parameters  <  e  1 , 82 , . « . ,  en )  to  this  activation. 

d)  set  up  the  following  procedures 

PROC  SYNC_RESET ; 

SYNC_RESET(av) ; 

END  PROC  SYNC_RESET; 

PROC  SYNC_WAIT; 

SYNC_WAIT(av) ; 

END  PROC  SYNC_WAIT ; 

PROC  SYNC_SIGNAL; 

SYNC_SIGNAL(av); 

END  PROC  SYNC_SIGNAL; 

PROC  TASK_END ; 

TASK_END( av> ; 

END  PROC  TASK.END; 

and  place  the  address  of  each  in  aa.  This  allows  access  to  the  high-level  scheduler,  given  only 
the  low-level  activation  variable  aa. 

©>  elaborate  the  following  procedure  invocation: 

TA5K_START ( av , aa ) ; 

For  activations  scheduled  by  the  ACT  scheduler  (i.e.,  when  av  has  type  ACT),  this  invokes  the 
ACT  scheduler  operation  that  starts  up  the  activation.  For  activations  scheduled  by  a 
user-defined  scheduler,  this  Invokes  the  operation  required  for  that  scheduler. 

TASK  COMPLETION 

When  a  task  activation  has  completed  the  elaboration  of  the  task  body,  the  invocation 
TASK_END(ME) ; 

is  elaborated.  This  allows  the  scheduler  to  remove  the  activation  from  its  queues. 
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14.5.4  EXAMPLE  -  A  ROUND  ROBIN  SCHEDULER 

CAPSULE  round_rob1n  (time.sllce  :  INT)  EXPORTS  rr_act, 
task_start,  task_end,  sync_reset,, 
sync_wa1tf  sync_s1gnal; 

CONST  max  :=  256;  X  maximum  number  of  activations  to 

X  be  scheduled 
TYPE  rr_act  ;  INTO.. max); 

VAR  n  :  INT(0..max)  :=  0;  X  Index  of  last  q  entry  In  use 
VAR  curr  :  INT<l..max)  :=  1;  X  Index  of  activations 

X  currently  scheduled 

VAR  dlock  :  DATAJ.OCK; 

VAR  asched  :  ACT;  X  scheduler  activation 

VAR  q  ;  ARRAY  lNf(l..max)  OF  ACT;  X  activations  to  be 

X  be  scheduled 

PROC  task_start  (VAR  r  :  rr_act,  VAR  a  :  ACT)  IMPORTS  ALL; 
REGION  dlock; 

ASSERT  n  <  max; 
n  :=  n  +  1; 
q(n)  :=  a; 
r.ALL  :=  n; 

SUSPEND  (a); 

TASK_START  <a,a); 

SYNC_SIGNAL  (asched); 

END  REGION; 

END  PROC  task_start; 

PROC  task_end  (VAR  r  :  rr_act)  IMPORTS  ALL; 

CONST  1  ;=  r.ALL; 

VAR  victim  :  act; 

REGION  dlock  DO; 
victim  ;=  q< 1 ) ; 
q(  1 )  :=  NIL.ACT; 

END  REGION; 

LOW_TASK_END  (victim); 

END  PROC  task_end; 
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PROC  sync_wait  (VAR  r  • 
LO W_S  YNC_WA I T ; 
SYNC_SIGNAL  (asched); 

END  PROC  sync_vait; 


rr_act>  IMPORTS 

X  signal  that 
%  activation 


asched; 

a  non-waiting 
is  available 


PROC  sync_reset  (VAR  r 
LGW_SYNC_RESET; 

END  PROC  sync_reset; 


rr_act); 


PROC  sync.slgnal  (VAR  r  :  rr  act) 

cL2W"SYNC-SIGNAL  <q<r.ALL>7; 

END  PROC  sync_s igna 1 ; 


IMPORTS  q; 


IA5K  scheduler  IMPORTS  ALL; 

WHILE  TRUE  REPEAT 
REGION  dlock  00 

VAR  new  :  INT(  1 .  .max+I)  :=  curr; 

X  search  for  next  available  activation 
loop  WHILE  TRUE  REPEAT 


new  :=  new  +  l; 
IP  new  >  n  THEN 


new  : =  new  -  n; 

END  IF; 

IFEme?ln=  NIHCT  T  N0T  WAITING  THEN 

txiT  loop;  %  found  one 

END  IF; 

X  all  waiting  or  dead 

X  leave  region 
X  wait  for  a  new  task_start 
X  the  end  of  a  sync_wa1t 
X  reenter  region 


X  schedule  next  activation 
IF  q(curr)  /r  NILJ1CT  THEN 
SUSPEND  (q(curr)); 

END  IF; 

UNSUSPEND  (q(new)); 
curr  :=  hew; 

ENO  IF; 

END  REGION; 

DELAY  (t1me_sl1ce); 

END  REPEAT; 

END  TASK  scheduler; 


IF  new  s  curr  THEN 
SYNC.RESET; 
UNLOCK  (dlock); 
SYNC.WAIT; 

LOCK  (dlock); 

END  IF; 

END  REPEAT  loop; 

IF  new  /=  curr  THEN 


q<l)  ;s  NIL.ACT; 

SET.PRIORITY  (asched,  255); 
CREATE  scheduler  NAMED  asched; 

END  CAPSULE  round_rob1n; 
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14.6  LOW-LEVEL  I/O 

Low-level  I/O  is  provided  to  ailow  low-level  access  to  the  most  primitive  level  of  I/O  provided  in 
the  target  computer.  The  high-level  I/O  described  in  Appendix  A  can  be  defined  using  tow-level  I/O, 
together  with  the  Interrupt  handling  facilities  described  in  Section  14.1A 


Invocation  of 

L0W_I0  (device,  command,  data); 

will  cause  the  specified  command  to  be  issued  for  the  specified  device,  using  the  specified  data.  If 
there  is  no  data  needed,  the  invocation 

LOW_IO  (device,  command); 

may  also  be  available.  The  types  of  each  of  the  parameters  Is  Implementation-dependent.  The  effect 
of  LOW_IO  is  implementation-dependent. 

EXAMPLE 

1)  360  example 

TYPE  CCWPTR  j  PTR  CCW; 

VAR  CAW  :  CCWPTR  LOCATION  (72); 

VAR  STATUS  :  10-STATUS; 

CAW  :s  ...  X  compute  address  of  CCW 

L0W_I0  (device,  'SIO);  X  executes  an  SIO  for  the 

X  specified  device 

•  »  « 

LOW_IO  (device,  'TIO,  STATUS);  X  executes  a  TIO  for  the 

X  specified  device  and 
X  returns  result 
X  In  STATUS 
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A.  HIGH-LEVEL  I/O 

This  appendix  discusses  a  recommended  set  of  definitions  for  user-level  input-output 
programming.  Thu  definitions  in  this  set  include  file  types  and  the  procedures  and  functions  which 
operate  on  files.  Files  may  be  defined  and  associated  with  external  physical  files  or  devices.  Physical 
files  may  be  created,  deleted,  and  renamed.  The  files  may  be  organized  for  either  sequential  or 
random  access  and  may  be  defined  as  either  input,  output,  or  update  files.  Files  may  be  read  or 
written  and  positioned  to  any  component.  Files  may  be  interrogated  to  determine  current  size  or 
position  or  to  ascertain  if  the  current  position  is  at  the  end  of  the  file.  Additional  file  processing 
facilities  are  provided  for  files  whose  components  are  characters  (i.e.,  have  an  ENUM  type).  Tht 
facilities  allow  strings  of  multiple  characters  to  be  read  or  written  by  a  single  Invocation. 

A.!  FILE  VARIABLES,  OPEN,  AND  CLOSE 

A  file  is  a  variable  having  a  FILE  type.  A  file  is  associated  with  an  ,  .  collection  of 
components,  all  having  the  same  type.  The  type  property  list  specifies  the  /fa  o»  the  components 
and  the  constraint  property  list  specifies  the  access  method  (sequential  or  random)  and  the  file  use 
(input,  output,  cr  update).  For  example, 

VAR  1nt_f lie  :  FILE  [INT(m1n. .max)]  ( 'SEQ,  'INPUT); 

defines  1nt_f11e  as  a  sequential  file  whose  components  are  integers  in  the  range  min  through  max. 
The  file  is  usable  for  input  processing  only.  Note  that  the  type  of  1nt_f11e  is  FILE  tINT]. 

Before  any  file  processing  can  occur,  the  file  must  be  associated  with  a  physical  file.  A  physical 
file  can  be  a  file  on  a  storage  medium,  a  physical  device,  or  a  file  on  a  storage  medium  representing  a 
physical  device  (for  example,  a  spooled  card  reader  file).  The  association  is  made  by  the  OPEN 
procedure,  which  also  serves  to  specify  the  initial  state  of  the  file  (old  or  new).  If  the  initial  state  of 
the  file  was  new,  a  file  is  created  and  its  name  placed  in  the  file  direcfory.  If  processing  i3  attempted 
before  a  file  is  opened,  an  exception  is  raised.  Assignment  is  not  defined  for  file  variables. 

After  all  file  processing  has  been  completed,  a  file  may  be  closed  by  the  CLOSE  procedure,  which 
severs  the  association  with  the  physical  file  and  specifies  subsequent  file  disposition  (save  or  delete). 

Although  old,  new,  save,  and  delete  do  not  apply  to  all  physical  devices,  they  are  required  for  files 
associated  with  such  devices.  If  the  initial  state  or  final  disposition  do  not  make  sense,  they  are 
ignored.  Requiring  this  information  makes  the  program  more  pr^able,  since  physical  devices  are 
commonly  represented  by  files  on  a  storage  medium.  A  file  ?  sociated  with  a  card  reader,  for 
example,  can  later  be  associated  with  a  spooled  card  reader.  Typ  cal  examples  of  file  use  are  shown 
below: 

1)  File  associated  with  file  on  storage  medium 

VAR  1nt_f11e  :  FILE  tlNKmln.  .max)]  ('SEQ,  'INPUT); 

OPEN  <1nt_f11e,  "ABC,  'OLD); 

...  X  f tie  processing 

CLOSE  (1nt_f11e,  'SAVE); 

2)  File  associated  with  physical  device 

VAR  printer  :  FILE  [ASCII]  ( 'SEQ,  ’OUTPUT); 

OPEN  (printer,  "00E",  'OLD); 

...  X  text  printing 
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CLOSE  (printer,  'SAVE) ; 


luentia!  and  Random  Files 


A  sequential  file  is  a  file  which  is  processed  by  accessing  each  component  In  succession.  A 
random  file  is  a  file  which  permits  direct  acces  to  any  component  regardless  of  its  position  with 
respect  to  olher  components.  Not  all  processing  procedures  and  functions  are  valid  on  sequential  files 
(i.e.,  a  card  reader  cannot  be  backed  up  to  the  start  of  the  file  after  some  reading  has  occurred). 


Text  and  Standard  Files 


Any  file  whose  components  have  an  enumeration  type  (i.e.,  ASCII  or  some  other  character  type)  is 
called  a  text  file.  All  other  files  are  called  standard  files.  There  are  two  predefined  text  files,  SYS_IN 
and  SYS„OUT,  which  are  files  of  ASCII.  A  set  of  procedures  and  functions  is  available  for  reading  and 
writing  text  files  in  a  line-oriented  manner.  Formatting  is  achieved  by  combining  text  files  with 
string-conversion  functions. 


VAR  text_f11e  :  FILE  [ASCII]  ('SEQ,  'INPUT); 

OPEN  (text_fi1e,  "SYSTEM",  !0LD); 

...  X  text  file  processing 
CLOSE  < text_f lie,  'DELETE); 

File  Use 

An  input  file  is  a  file  which  is  read-only.  An  output  file  is  a  file  which  is  write-only.  An  update 
file  Is  a  file  which  may  be  read  or  written. 
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A.2  FILE  PROCESSING 

File  processing  is  accomplished  by  the  READ,  WRITE,  SET_POSITION,  and  FILE_RENAME 
procedures  and  the  SIZE,  POSITION,  and  EOF  functions. 

READ  and  WRITE 


READ  moves  data  from  an  input  or  update  file  to  a  variable  defined  to  be  of  the  component 
subtype.  After  the  READ,  the  file  position  is  increased  by  one.  WRITE  moves  data  from  a  variable  of 
the  component  subtype  tc  an  output  or  update  file.  After  the  WRITE,  the  file  position  is  It  creased  by 
one.  If  the  data  was  written  at  the  end  of  the  file,  the  size  of  the  file  is  Increased  by  one. 

VAR  1nt_f lie  :  FILE  CINT(0. .100)]  CSEQ,  'INPUT); 

OPEN  (int.flle,  "ABC",  'OLO); 

FOR  1  :  INT(1..25)  REPEAT  X  process  first  25  components 
VAR  temp  :  INT<0..100); 

READ  (int_f11e,  temp); 
process  (temp); 

END  REPEAT; 

CLOSE  (1nt_f11e,  'DELETE); 

POSITION 

POSITION  returns  the  current  file  position.  If  the  file  is  positioned  at  the  start  of  the  file  (before 
the  first  component),  POSITION  will  return  1.  When  a  file  is  opened,  the  position  will  be  1.  When  a 
file  is  closed,  the  position  is  after  the  last  record.  If  the  file  is  positioned  at  the  end  of  the  file  (after 
the  last  component),  POSITION  will  return  the  number  of  components  in  the  file  plus  one. 

SET_POSITION 

SET_POSITION  moves  a  file  to  a  specified  position.  If  an  attempt  is  made  to  position  the  file 
before  1  or  past  the  end  of  the  file,  an  exception  is  raised. 

The  procedure  invocation 

SET_POSITION  (any_f11e,  1); 
is  equivalent  to  a  rewind  command. 

The  procedure  invocation 

SET_POSITION  (any_f  11ef  POSITION! any_f lie)  -  1); 
is  equivalent  to  a  backspace  command. 


SIZE  returns  the  number  of  components  in  a  file.  If  the  file  Is  empty,  SIZE  returns  zero.  The 
following  example  positions  a  file  to  its  end  and  writes  a  new  component. 


SET.POSITION  (any_f11o,  SIZE(any_f He)  +  1); 
WRITE  (any_f11e,  temp); 
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EOF  returns  a  boolean  value  signifying  whether  the  position  is  at  the  end  of  a  file.  If  the  file  Is 
positioned  at  its  end,  EOF  returns  TRUE.  For  example, 

EOF  (any_f lie) 


FILE_RENAME 

FILE_RENAME,  in  the  presence  of  a  file  system,  changes  the  name  of  an  existing  physical  file.  Any 
associations  made  between  files  and  that  physical  file  continue  to  exist.  The  old  file  name,  however, 
can  no  longer  be  used. 

OPEN  ( 1nt_f lie,  "ABC",  'OLD); 

FILE.RENAME  ("ABC",  "XYZ");  X  1nt_f11e  Is  still  associated 

X  with  the  same  physical  file, 

X  which  Is  now  known  by 
X  another  name 

OPEN  ( 1nt2_f He,  "ABC",  'OLD);  X  Illegal,  file  "ABC"  Is  now 


X  unknown 


EXAMPLES 


1)  Copies  entire  file 

VAR  1n_f 1 1e  :  FILE  tINT(l.. 100)3  ('SEQ,  'INPUT); 

VAR  out_f lie  :  FILECINTU .. 100)3  ( 'SEQ,  'OUT); 

OPEN  ( 1n_f lie,  "ABC",  ’OLD); 

OPEN  (out_f 1 1e,  "XYZ",  'NEW); 

WHILE  NOT  EOF( 1n_f11e)  REPEAT 
VAR  temp  :  INK  1..  100); 

READ  ( 1n_f tie,  temp); 

WRITE  (out_f11e,  temp); 

END  REPEAT; 

CLOSE  ( 1n_f 1 1e,  'DELETE); 

CLOSE  (out_f 1 1e,  'SAVE); 

2)  Sequential  update  processing 

VAR  update.flle  :  FILE  (INK  1 .. 100)3  ( 'SEQ,  'UPDATE); 

OPEN  <update_f11e, '"ABC",  'OLD); 

WHILE  NOT  EOF(update_f11e)  REPEAT 
VAR  temp  :  INK  1..  100); 

READ  (update_f11e,  temp); 
temp  :=  temp  +1;  X  change  data 
SET.POSITION  (update_f lie, 

P0SITI0N( update_f lie)  -  1); 

WRITE  (update_f11e,  temp);  X  write  changed  data 

X  over  old  component 
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END  REPEAT; 

CLOSE  (update_f 1 1e,  'SAVE); 

3>  Copies  entire  file  n  times 

%  file  OPENs  and  CLOSEs  occur  outside  procedures  to 
X  avoid  trying  files  to  particular  physical  files 
PROC  copy  (n  :  INTO..  10)); 

FOR  1  ;  INT < 1 .  .n)  REPEAT 

WHILE  NOT  EOFC in_f 1 le)  REPEAT 
VAR  temp  :  INK  1..  100); 

READ  (1n_f11e,  temp); 

WRITE  (out_file,  temp); 

END  REPEAT; 

SET.POSITION  (In.file,  1);  X  rewind 
END  REPEAT; 

END  PROC  copy; 

Implementation-Dependent  Procedures  and  Functions 

It  is  anticipated  that  a  variety  of  implementation  and/or  device-dependent  procedures  and 
functions  will  be  available  for  setting  and  interrogating  file  characteristics  such  as  protection,  physical 
blocking,  buffering,  and  file  space. 

EXAMPLES 

1)  370  VS  example 

VAR  lib  :  FILEtASCII]  CSEQ,  'INPUT); 

SET_VOL  (lib,  "PRIVATE,RETAIN,SER=LIB003">; 

SET.UNIT  (lib,  "2314"); 

SET_DISP  (lib,  "SHR"); 

OPEN  (lib,  "XC0M.DTA3",  'OLD); 

2)  PDP-10  TOPS  10  example 

VAR  data  :  FILE[INT(  1 .  .50)]  CSEQ,  'OUTPUT); 

SET_PRT  (data,  "<057>");  X  set  protection  code 

SET_VER  (data,  4);  X  version  4 

OPEN  (data,  "DSKC:mydata.dat[10,50J",  'NEW); 
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A.3  TEXT  FILES 

A  text  file  is  a  file  whose  components  have  an  enumeration  type.  This  enumeration  type  will 
specify  a  character  set,  usually  ASCII.  The  following  example  defines  a  text  file  which  might  be  a  card 
reader. 

VAR  card_f lie  :  FILE  [ASCII]  ( 'SEQ,  'INPUT); 

OPEN  (card.flle,  "ABC",  'OLD); 

CLOSE  (card.flle,  'DELETE); 

Two  text  files  are  predefined,  SYS_IN  and  SYS_0UT.  These  must  be  opened  to  associate  them 
with  an  appropriate  physical  file  for  input  and  output. 

File  Processing 

It  is  possible  to  perform  character  by  character  processing  of  a  text  file  using  the  file  processing 
procedures  and  functions  already  described.  It  is  usually  more  convenient,  however,  to  think  of  a  text 
file  as  a  sequence  of  lines  rather  than  characters,  where  a  line  consists  of  the  string  of  all  characters 
up  to,  but  not  including,  the  carriage-return  line-feed  characters  ('CR  4  'LF).  For  example,  if  a  text 
fife  contains 

"ABC"  &  'CR  4  'LF  4  "DEFGH"  4  •  CR  4  'LF 

then  that  text  file  is  considered  to  be  composed  of  two  lines,  "ABC"  and  "DEFGH".  The  type  of  the 
characters  making  up  the  line  are  the  same  as  the  type  of  the  file  component.  As  shown  in  the  above 
example,  lines  within  the  same  file  may  be  of  different  lengths. 

The  READLN  procedure  and  the  WRITELN  procedure  are  provided  to  read  lines  from  and  write 
lines  to  text  files.  Also  provided  are:  a  SIZELN  function  to  interrogate  the  size  of  the  line  about  to 
be  read;  definitions  of  READLN,  SIZELN,  and  EOF  which  assume  that  the  file  name  is  the  predefined  file 
SYS_IN;  and  a  definition  of  WRITELN  which  assumes  that  the  file  name  is  the  predefined  file  SYS_OUT. 


READLN  and  WRITELN 

READLN  reads  a  line  from  an  input  or  update  text  file  into  a  variable.  After  the  READLN,  the  file 
position  is  increased  by  the  number  of  components  contained  in  the  line  just  read  plus  the  carriage 
return  and  line  feed.  WRITELN  writes  a  line  from  a  variable  of  the  component  subtype  into  an  output 
or  update  text  file.  After  the  WRITELN,  the  file  position  is  increased  by  the  number  of  components  in 
the  line  just  written  plus  the  carriage  return  and  line  feed. 

SIZILN 

SIZELN  returns  the  number  of  characters  between  the  current  position  end  the  first  end  of  line 
<  'CR  4  'LF>. 

EXAMPLES 


1 )  Echo  input  to  output,  one  line  at  a  time,  using  SYS_IN  and  SYS_0UT. 
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OPEN  (SYS_IN,  "ABC",  'OLD); 

OPEN  <SYS_OUT,  "XYZ",  'OLD); 

WHILE  NOT  EOF  REPEAT 

VAR  line  :  STRINGCASCII]  (SIZELN); 

READLN  (line); 

.  WRITE LN  (line); 

END  REPEAT; 

CLOSE  (SYS_IN,  'SAVE); 

CLOSE  (SYS.OUT,  'SAVE); 

2)  Echo  input  to  output,  one  line  at  a  time,  using  user-defined  text  files. 

VAR  1n_f  He  :  FILECASCII]  ( 'SEQ,  'INPUT); 

VAR  out_f lie  :  FILE  [ASCII]  ( 'SEQ,  'OUT); 

OPEN  ( 1n_f11e,  "ABC",  'OLD); 

OPEN  (out_f lie,  "XYZ",  'NEW); 

WHILE  NOT  E0F(1n_f11e)  REPEAT 

VAR  line  :  STRINGCASCII]  (SIZELN(  1n_f  He) ) ; 
READLN  ( 1n_f11e,  line); 

WRITELN  (out_f lie,  line); 

END  REPEAT; 

CLOSE  ( 1 n_f lie,  'DELETE); 

CLOSE  (out_f lie,  'SAVE); 


3)  Reverse  lines  from  SYS_IN  and  output  onto  SYS_0UT. 


OPEN  (5YS_IN,  "ABC",  'OLD); 

OPEN  (SYS_OUT,  "XYZ",  ’OLD); 

WHILE  NOT  EOF  REPEAT 

VAR  line  :  STRINGCASCII]  (SIZELN); 

READLN  (line); 

FOR  1  :  INK  1  ..  Ilne.LEN  DIV  Z)  REPEAT 
CONST  j  ;=  Ilne.LEN  +1-1; 

CONST  t  :=  line  (1); 

1 ine  ( 1 )  :=  line  ( j) ; 
line  (J)  :=  t; 

•  END  REPEAT; 

WRITELN  (line); 

END  REPEAT; 

CLOSE  (SYS_IN,  'SAVE); 

CLOSE  (SYS.OUT,  'SAVE); 

Conversions  Upon  Input 

Conversions  are  defined  from  strings  to  booleans,  integers,  floating  point  numbers,  and 
enumeration  values.  Any  leading  or  trailing  blanks  in  the  input  strings  are  ignored.  The  form  of  the 
remaining  characters  must  be  a  legal  literal  of  the  type  to  which  the  form  will  be  converted,  with  an 
optional  plus  or  minus  sign  preceding  an  integer  or  floating  point  literal.  If  the  minus  sign  Is  present, 
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the  literal  will  be  converted  to  a  negative  value. 

If  an  integer  or  floating  point  subtype  is  specified  as  the  target  of  the  conversion,  the  string 
literal  must  be  within  the  target  range  or  an  exception  is  raised.  If  the  string  literal  has  more 
precision  than  the  target  floating  point  subtype,  truncation  is  performed. 

Conversions  Upon  Output 

Conversions  are  defined  from  booleans,  integers,  floating  point  numbers,  and  enumeration  values 
to  strings.  Each  value  is  converted  to  the  literal  form  and,  if  the  value  is  a  negative  Integer  or  floating 
point  number,  a  minus  sign  is  inserted  before  the  integer  or  floating  point  life-  at.  The  format  of  a 
string  literal  of  a  floating  point  number  is  an  optional  minus  sign  followed  by 


or 


n .nnnnE+mmm 

n.nnnnE-mmm 


where  the  number  of  n's  is  the  precision  of  the  floating  point  number. 

If  the  target  is  a  string  subtype  (that  is,  if  a  length  is  specified)  and  the  length  is  longer  than  the 
string  literal,  the  string  is  padded  on  the  left  with  blanks.  If  the  length  is  shorter  than  the  string 
literal,  an  exception  is  raised. 


EXAMPLES 

1)  Reads  in  a  line  which  contains  only  an  integer.- 

VAR  line  :  STRINGtASCII]  (SIZELN); 

READLN  (line); 
s  :=  CNVT  [INTj  (line); 

2)  Writes  out  a  line  which  contains  only  an  integer. 

WRITELN  (CNVT  [STRING  [ASCII]]  (O); 

3)  Reads  lr»  a  line  which  contains  two  integers,  one  in  the  first  five  columns  and  the  next  In  the 
second  five  columns. 

VAR  1,j  :  INK  1.. 50); 

ASSERT  SIZELN  >=  10; 

VAR  s  :  STRING[ASCII]  (SIZELN); 

READLN  (s); 

1  :=  CNVT  [INT]  (s(1..5>>; 
j  :=  CNVT  [INT]  (s(6..10>); 

Output  Formatting 

To  simplify  the  conversion  of  floating  point  numbers  to  ASCII  strings  for  output,  tv/o  format 
functions  are  provided  in  addition  to  the  standard  conversion  function. 

A  floating  point  number  can  be  output  without  an  exponent  by  invoking  the  FORMAT  function  and 
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passing  the  floating  point  value,  the  number  of  characters  to  be  output  to  the  loft  of  the  decimal  point, 
and  the  number  of  characters  to  be  output  to  the  right  of  the  decimal  point.  Zeros  on  the  left  are  not 
suppressed.  If  the  value  is  negative,  a  minus  sign  is  output  to  the  left  of  the  string.  The  total  number 
of  characters  in 

FORMAT  < f loat_number,  n,  m) 

is  n  +  in  +  2  <for  the  sign  and  decimal  point).  If  the  first  significant  digit  would  be  lost,  the 
X_FORMAT  exception  is  raised. 

A  floating  point  number  can  be  output  with  an  exponent  by  invoking  the  FORMAT  function  with 
one  additional  parameter,  the  number  of  characters  to  be  output  to  the  right  of  E.  The  sign  of  the 
exponent  will  always  be  printed.  The  first  significant  digit  will  appear  as  the  leftmost  character.  If 
the  value  is  negative,  a  minus  sign  is  printed  to  the  left  of  the  string.  The  total  number  of  characters 
in 


FORMAT  (f 1oat_number,  n,  m,  o) 


isn+m  +  o  +  4  (for  the  sign,  decimal  point,  E,  and  the  exponent  sign).  If  the  exponent  will  not  fit 
in  o  digits,  the  X_F0RMAT  exception  is  raised, 


EXAMPLES 


CNVT  [STRINGCASCII]] 
CNVT  [STRINGCASCII]] 
CNVT  [STRINGCASCII]] 
CNVT  [STRINGCASCII]] 
CNVT  [STRINGCASCII]] 
3.726E+2 
-5.00E+1 
1.00500E+4 
5.720E+2 
I . 000000000E-10 


(372.65) 

(-50.0) 

(10050.0) 

(572.0) 

(.0000000001) 


FORMAT  (372.65,  3,  3) 
FORMAT  (-50.0,  3,  3) 
FORMAT  (10050.0,  3,  3) 
FORMAT  (572.0,  3,  3) 
FORMAT  (.0000000001,  3,-3) 
372.650 
-050 . 000 
X_FORMAT 
572.000 
000.000 


FORMAT  (372.65,  3,  3,  3) 
FORMAT  (-50.0,  3,  3,  3) 
FORMAT  (10050.0,  3,  3,  3) 
FORMAT  (572.0,  3,  3,  3) 
FORMAT  (.0000000001,  3,  3,  3) 
372 .650E+000 
-500 .000E-001 
100 . 500E+002 
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572 .000E+000 
100 .000E-012 


INTERMETRICS  INC. 


Appendix  Q 


B.  PRAGMATS 


<§> 


220 


Appendix  B 


RED  LRM  8  March  1979 


Pragmats  supply  information,  that  does  not  affect  program  semantics,  to  the  translator.  Some 
pragmats  are  language-defined;  all  translators  are  expected  to  recognize  these  pragmats  (although  the 
translator  is  not  required  to  take  any  action).  A  translator  can  also  permit  additional  pragmats  to  be 
specified. 

RULES 

A  list  of  pragmats  can  appear  between  any  two  tokens  In  a  program.  Certain  of  the  pragmats  are 
further  restricted  in  where  they  can  appear.  The  restrictions  for  each  pragmat  is  given  below. 

OPTIMIZE 

This  pragmat  is  used  to  inform  the  translator  whether  or  not  to  optimize. 

If  the  OPTIMIZE  pragmat  appears  on  a  scope,  it  is  applied  to  this  scope,  and  to  all  scopes  nested 
within  this  scope  that  do  not,  themselves,  specify  an  OPTIMIZE  pragmat. 

If  the  OPTIMIZE  pragmat  appears  on  a  variable  or  constant  declaration,  it  controls  the 
representation  for  the  data  item. 

If  the  OPTIMIZE  pragmat  appears  on  a  type  declaration,  it  applies  to  the  representation  of  all  data 
items  having  that  type. 

SUPPRESS 

Each  of  the  identifiers  must  be  exceptions.  This  pragmat  indicates  that  no  code  need  be 
generated  to  check  for  any  of  the  listed  exceptions  during  elaboration  of  the  scope  on  which  it  Is 
specified.  Code  will  still  be  generated,  however,  for  the  guarded  bodies  of  guard  statements  which 
explicitly  handle  the  listed  exceptions.  If  the  exception  actually  occurs,  the  effect  is  undefined. 

OPEN  and  CLOSED 

These  pragmats  are  specified  on  a  deferred  declaration  or  an  an  invocation  of  a  deferred 
declaration.  On  a  deferred  declaration,  they  refer  to  all  invocations.  On  an  invocation,  they  refer  to 
only  that  specific  invocation.  OPEN  requests  the  translator  to  attempt  to  compile  the  invocation  open 
(inline).  CLOSED  requests  the  translator  to  attempt  to  compile  the  invocation  closed  (out  of  line). 

USI 

This  pragmat  can  be  specified  between  any  two  tokens.  LIST(OFF)  specifies  that  the  source 
listing  is  not  to  be  printed  until  the  next  LIST(ON)  pragmat  appears. 

NONRECURSIVE  and  NONREENTRANT 

These  pragmats  can  be  specified  on  a  deferred  declaration.  They  are  used  to  inform  the  translator 
that  the  deferred  declaration  will  not  be  invoked  recursively  (*.e.,  during  Its  own  elaboration)  or 
reentrantly  (simultaneously  by  two  or  more  activations).  If  the  translator  or  linker  discovers  that 
these  pragmats  were  wrong,  an  error  will  be  issued. 

QK 

This  pragmat  is  used  to  turn  off  warning  messages  issued  by  the  translator  when  It  discovers  that 
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dangerous  aliasing  or  dangerous  sharing  will,  or  might,  occur.  The  OK  (ALIAS)  pragmat  can  appear 
either  on  deferred  declarations  or  an  invocations.  The  OK(SHARE)  pragmat  can  appear  on  variable 
declarations,  constant  declarations,  and  formal  parameter  definitions. 

Placement  of  Pragmats 

Pra.gma.ts  can  appear: 

a)  On  a  scope.  The  pragmat  must  appear  immediately  before  the  first  token  of  the  scope.  For 
example, 


PRAG  (SUPPRESS  <X_INIT>)  BEGIN 
PRAG  (OPTIMIZE  (SPACE)) 

•  •  • 

PRAG  (OPTIMIZE  (TIME))  PROC  p; 

END  PROC  p; 

END; 

b>  On  a  variable  declaration,  constant  declaration,  formal  parameter  definition,  or  actual  parameter. 
The  pragmat  must  appear  between  the  last  token  and  the  terminating  or  or  T.  For 
example, 


VAR  x  ;  INT(0 . .  10)  OPTIMIZE  (TIME); 
PROC  q  (VAR  y  :  INTO.  .10) 

PRAG  (OK  (SHARE))  IMPORTS  x; 

END  PROC  q; 

q  (x  PRAG (OK (ALIAS))  ); 


c)  On  a  deferred  declaration.  For  compound  declarations,  the  pragmat  must  appear  immediately 
before  the  ";H  terminating  the  header.  For  type  and  abbreviation  declarations,  the  pragmat  must 
appear  immediately  before  the  terminating  For  example, 

TYPE  t  :  INT ( 0 . . 10)  PRAG  (OPTIMIZE  (TIME)); 

PROC  p  (v  :  BOOL)  IMPORTS  w  PRAG  (OPEN); 

END  PROC  p; 

FUNC  q  (x  :  t)  =>  t  PRAG  (NONRECURSIVE,  NONP.EENTRANT) ; 

ENDFUNC  q; 
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C.  BUILT-IN  TYPES 
c,i  BOOL 
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C.2  ENUM 

Subtype  Forms 

1)  ENUMEel l,el2, . . .,e1n] 

2)  ENUMEeU,el2, . . . ,eln3<m1n. .max) 

where  el's  are  enumeration  literals  and  min  and  max  are  expressions  with  type 
ENUMtel  1  ,e12, . .". ,  eln].  A  single  literal  may  appear  only  once  In  the  extension.  Form  1  Is 
equivalent  to 

ENUMEel 1 ,e12 . eln](ell .  .eln) 

Values 

The  values  are  the  enumeration  literals  that  appear  in  the  type  property  list  restricted  to  the 
range  min.  .max  .  The  values  are  ordered  so  that  if  i<j  then  eli<elj. 

Literals;  all  enumeration  literals. 


Operations 

Purpose 

successor 

predecessor 

position 

equality 

ordering 

assignment 


Operations  Notes 


SUCC(ENUM)=>ENUM  1 

PRED(ENUM)=>ENUM  1 

POS<ENUM)=>INT  2 

=( ENUM, ENUM )=>B00L  3 

<< ENUM, ENUM )=>B00L  3 

:=< ENUM, ENUM)  3,4 


1)  The  result  subtype  is  the  subtype  of  the  actual  parameter.  X_RANGE  Is  raised  for  the  successor 
of  the  last  value  and  the  predecessor  of  the  first  value. 

2)  When  the  actual  parameter  has  type  ENUMCell,el2, . .  .eln]  and  value  ell,  then  the  result 
has  subtype  INT ( 1 . .  n )  and  value  1. 

3)  Both  operands  must  have  the  same  type. 

4)  X_RANGE  is  raised  if  the  source  value  is  not  valid  for  the  target  subtype. 


Attribute  Inquiry 

Attribute 

Result  Subtype 

Result  Value 

ENUME . . .  3<m1n. .max) .MIN 

ENUME . 

. .3(min. .max) 

min 

ENUMC . . . 3(min .  .max) .MAX 

ENUME. 

. .3(m1n..max) 

max 

INTERMETRICS  INC. 


Appendix  C.3 


225 


C.3  !NT 

Subtype  Form 

INT(m1n. .max) 

where  min  and  max  are  expressions  having  type  INT.  If  the  values  of  min  or  max  exceed  the 
implementation  defined  largest  range,  then  X_MAXRANGE  is  raised. 

Values 


Integers  (whole  numbers)  in  the  range  min.  .max  . 
Literals:  All  integer  literals. 


Operations 

Purpose 

plus 

minus 

addition 

subtraction 

multiplication 

exponentiation 

modulo 

division 

successor 

predecessor 

equality 

ordering 

absolute  value 

assignment 

conversion 


Operation  Notes 

+( INT)=>INT  1 

-( INT)=>INT  1 

+{ INT, INT)=>INT  1 

-<INT,INT)=>I?rr  1 

*( INT, INT)=>INT  1 

**( INT, INT)=>INT  1,2 

MOD(  INT,  INT)=>INT  1,3,4 

DIV(  INT,  INT)  =  >INT  1,3,4 

SUCC(INT)=>INT  5 

PRED(INT)5>INT  5 

-( INT,  INT)=>B00L 
<(INT,INT)=>B00L 
ABS(INT)=>INT  1 

:=( INT, INT)  6 

IFLOAT(INT,INT)s>FLOAT  7 


1)  Result  subtype  is  INT(  Imin,  Imax),  where  Imln  and  Imax  values  are  selected  by  the 
implementation  so  that  any  result  value  will  be  included  in  the  range.  Note,  however,  that  this 
range  will  never  exceed  an  implementation  defined  largest  range  even  if  result  values  outside 
this  range  are  possible.  If  this  largest  range  is  exceeded,  X_OVERFLOW  is  raised. 

2)  Raises  X_NEG_EXP  if  the  value  of  the  second  actual  parameter  value  is  less  than  zero.  1**0=1 

3)  Raises  X_ZERO_DIVIDE  if  the  the  value  of  the  second  actual  parameter  is  zero. 

4)  The  following  identities  hold: 
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a)  X=Y*(X  DIV  Y>  ♦  (X  MOO  Y) 

b>  Either  X  MOD  Y  =  0  or  X  MOD  Y  and  Y  have  the  same  algebraic  sign. 
c>  ABS( X  MOD  Y)  <  ABS(Y) 

5)  The  result  subtype  is  the  subtype  of  the  actual  parameter.  X_RANGE  is  raised  for  the  successor 
of  the  last  value  and  the  predecessor  of  the  first  value. 

6)  Raises  X_RANGE  if  the  source  value  is  not  valid  for  the  target  subtype. 

7)  This  function  is  used  to  convert  an  integer  to  a  floating  point  value.  The  first  actual  parameter 
is  the  precision  of  the  result  and  must  be  manifest.  The  second  actual  parameter  is  the  integer 
to  be  converted.  See  note  1  under  FLOAT  concerning  the  range  of  the  result. 


Attribute  Inquiry 

Attribute 

Result  Subtvoe 

Result  Value 

INTtmln . .max) .MIN 

INTtmln. .max) 

min 

INT<m1n. .max) .MAX 

INTtmln. .max) 

max 

INTERMETRICS  INC. 
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C.4  FLOAT 

Subtype  Form 

FLOAT(prec,min. .max) 

where  prec  has  type  INT  and  must  be  manifest  and  min  and  max  are  expressions  having  type  FLOAT. 
If  the  value  of  prec  exceeds  an  implementation  defined  largest  precision,  or  if  the  values  of  min  and 
max  exceed  an  implementation  defined  largest  range,  then  X_MAXRANGE  is  raised. 

Values 


Approximate  floating  point  numbers  having  precision  prec  in  the  range  min.  .max  .  The  precision 
is  the  minimum  number  of  decimal  digits  to  be  represented.  For  values  around  zero  there  Is  a  smallest 
non-zero  absolute  value  that  is  implementation  dependent. 

Literals:  All  FLOAT  literals. 


Operations 

Purpose  Operation  Notes 


plus 

minus 

addition 

subtraction 

multiplication 

division 

exponentiation 

equality 

ordering 

absolute  value 

assignment 

conversion 


+{FLOAT)=>FLOAT  1 

-( FLOAT )=>F LOAT  1 

+ (FLOAT, FLOAT )=>FL0AT  1 

-(FLOAT, FL0AT)=>FL0AT  1 

*  <  F  LOAT , F  LOAT ) = >F  LOAT  1 

/(FLOAT, FLOAT)=>FLOAT  1,2 

♦♦{FLOAT, INT)=>FL0AT  1,3 

* ( F  LOAT , F  LOAT ) = >B00L 
< ( F  LOAT , F  LOAT ) = >  BOOL 
ABS(FLOAT)s>FLOAT  1 

:=(FL0AT, FLOAT)  A 

FLOOR ( FLOAT )=> INT  5,6 


1)  Result  subtype  is  FLOAT(prec,  Imin .  .imax)  where  prec  is  the  maximum  of  the  precisions  of 
the  actual  parameter(s).  Imin  and  Imax  values  are  selected  by  the  implementation  so  that  any 
result  value  will  be  included  in  the  range.  Note  however  that  this  range  will  never  exceed  an 
implementation  defined  largest  range  even  if  result  values  outside  this  range  are  possible.  If 
the  largest  range  is  exceeded,  X_0VERFL0W  is  raised. 

2)  Raises  X_ZER0_DIVIDE  if  the  value  of  the  second  actual  parameter  is  zero. 
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Mppenaix  C.4  ocn  ,  D. .  _  . , 

3>  =  1.  Raises  X_NEG  EXP  „  ,  M*,Ch  1979 

4)  Raises  X  RANGF  ~  lhe  sec0"d  parame,=r  Is  less  than  aero. 

than  the  "source,  ^To^rloZ^  *»*  -btypo.  I,  the  tar,.,  has  less  prociston 


5)  Rounds  any  fractional  part  down.  FLOOR(X)  <•  X 

6)  See  note  1  under  INT  operations. 


Attribute  Inguir^/ 
Attribute 

FLOAT(prec,m1n . 
FLOAT(prec,m1n. 
FLOAT(prec,min. 


radix 

minimum  exponent 
maximum  exponent 


Result  Subtype 

INTtprec. .prec) 
FL0AT(prec,m1n. .max) 
FLOAT(prec,mtn. .max) 


Operation 

ACTP< FLOAT )=>INT 
RADIX(FLOAT)=>INT 
EMIN(FLOAT)=>INT 
EMAX(FLOAT)=>INT 


•  ■  V 


.max) .MIN 

.max). MAX 

Machine  Dependent  Inquiry  FtmrU». 
Purpose 

actual  precision 


Result  Value 

prec 

min 

max 
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C.5  RECORD 

Subtype  Form 

RECORDC1di:Sl,1d2:S2 . 1dn:Sn] 

If  several  adjacent  components  have  the  same  subtype,  then 

1  d  1 ,  ldl+1 . Id j :S 

can  be  used  as  a  shorthand  for 

Idl  :S,  ldl  +  1  :S . 1dJ:S 

Values 

An  ordered  set  of  name-value  pairs,  one  for  each  identifier,  where  the  name  of  the  I'th  value  Is 
idi  and  the  subtype  of  the  i'th  value  is  St. 

Components 

A  record  variable  (or  constant)  is  made  up  of  one  or  more  component  variables  (or  constants). 
Each  component  is  named  by  a  distinct  identifier.  The  components  may  have  different  subtypes. 

Constructor:  See  Section  5.6. 

Operations 

Purpose  Routine  Notes 

equality  =( RECORD, RECORD )=>BOOL  1,2 

assignment  :  s  ( RECORD ,  RECORD )  1,3 

1)  Actual  parameters  must  have  the  same  type. 

2)  Each  of  the  component  types  must  have  =  defined.  Each  of  the  components  are  compared  using 
=  for  the  component  type. 

3)  Each  of  the  component  types  must  have  :=  defined.  Each  of  the  components  are  assigned  in  a 
undefined  order  using  the  :=  for  the  component  type. 

Record  Component  Selection 
The  result  of 


R.C 


where  R  has  a  RECORD  type  is  component  C  of  record  R.  The  result  Is  a  variable  If  R  is  a  variable. 
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C.6  UNION 

Subtype  Forms 

1)  UNIONC  Idl  :S1 ,  1d2  :S2 . 1dn:Sn] 

2)  UNIONC  Idl  :Sl,1d2;S2 . IdnrSnHexp) 

where  exp  has  type  ENUMC’Idl,  Md2,...,'1dn].  None  of  the  Idl  may  be  TAG.  If  several 
components  have  the  same  subtype  then 

Idl , ldl+1, .... 1dj:S 
can  be  used  as  a  shorthand  for 

Idl :S, ldl+1 :S, ...» 1dJ:S 

Values 

The  discriminated  union  of  the  values  of  each  of  the  component  subtypes.  Equivalently,  a 
tag-value  pair  in  which  the  subtype  of  the  value  is  the  one  named  by  the  tag.  Variables  having 
subtypes  of  form  2  may  only  have  values  whose  tag  is  the  value  of  exp. 

Components 

At  any  time  a  union  variable  for  constant)  has  exactly  one  named  component  variable  (or  constant). 
Consider 


UNIONC  idl  :S1 , id2  :S2 . 1dn:Sn] 

The  possible  component  names  are  idl,  id2,  ...»  Idn.  The  current  component  name  is  called  the 
tag.  When  the  tag  is  idi,  the  component  variable  (or  constant)  has  subtype  Si. 

Constructor:  See  Section  5.6. 

Operations 

Purpose  Operation  Notes 

equality  =(  UNION,  UNION  )  =  >BOOL  1,2 

assignment  :  =  (UNI0N, UNION)  1,3 

1)  Actual  parameters  must  have  the  same  type. 

2)  Each  of  the  component  types  must  have  s  defined.  Result  is  true  If  types  are  equal  and  the 
current  components  are  equal. 

3)  Each  of  the  component  types  must  have  :s  defined.  The  component  Is  assigned  using  :»  for  Its 
type.  X_RANGE  Is  raised  if  the  source  is  not  valid  for  the  target. 
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The  resuit  of 


U.C 


where  U  has  a  UNION  type  is  component  C  of  union  U.  If  the  selected  union  component  is  not 
currently  present,  then  the  X_TAG  exception  is  raised.  The  result  is  a  variable  if  U  is  a  variable.  The 
result  of 


U.TAG 

is  a  value  with  subtype  ENUNl '  Idl , '  1d2, . . . , '  tdnl  where  the  Id's  are  the  component  names  of 
the  UNION  type  of  U  in  order.  The  result  value  is  the  name  of  the  component  currently  held  by  the 
union.  1 
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C.7  ARRAY 


Subtype  Form 

ARRAY  tndexl,  index2, . . . ,  Indexri  OF  comp 

This  is  the  subtype  for  an  n-dimensional  array  whose  index  subtypes  are  Indexl, 
index2,~,indexn.  The  component  subtype  is  comp.  Each  index  subtype  must  be  either  an  INT  or 
ENUM  subtype. 

Values 

Arrays  of  values  of  the  component  subtype,  where  there  Is  one  value  In  the  array  for  each 
combination  of  values  of  the  index  subtypes. 

Components 

An  array  variable  (or  constant)  has  zero  or  more  components,  variables  (or  constants),  all  with  the 
same  component  subtype.  A  component  is  selected  by  supplying  a  value  for  each  index.  Note  that  if 
any  index  subtype  has  no  values,  the  array  will  have  no  components. 

Constructor:  See  Section  5.6. 


Operations 


Purpose 


Operation 


Notes 


equality 

concatenate 

assignment 


a  (ARRAY,  ARRAY  )s>B00L  1,2 

&<ArtRAY,ARRAY)s>ARRAY  1,3,4 

:  =  ( ARRAY, ARRAY)  1,3,5  * 


1)  Actual  parameters  must  have  the  same  type. 

2)  The  component  type  must  have  =  defined.  The  result  is  true  if  the  index  subtypes  are  equal 
and  corresponding  components  are  equal. 

3)  The  component  type  must  have  :=  defined.  Components  are  assigned  using  :=  for  the 
component  type.  If  the  source  and  target  overlap  assignment  is  done  in  such  a  way  that  a 
target  component  will  not  be  modified  before  its  use  as  a  source  component. 

4)  Only  1 -dimensional  arrays  whose  index  type  is  INT  may  be  used  as  actual  parameters.  If  the 
actual  parameters  have  respectively  m  and  n  components,  then  the  index  subtype  of  the  result 
is  INT(  1  ...m+n). 

5)  X_ARRAY  is  raised  if  the  number  of  values  in  the  corresponding  Index  subtypes  of  the  source  • 

and  the  target  are  not  equal.  , 


Index  Subtype 


INDEXOF  is  described  in  Section  4.5.1. 
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The  result  of 

A<expl,exp2, .  ..,expn) 

where  A  is  a  n-dimensional  array  and  the  type  of  each  expi  Is  the  i'th  index  type  of  the  array  Is  the 
component  of  A  at  position  specified  by  the  value  of  the  exp's.  If  the  value  of  any  exp  is  not  valid  for 
the  corresponding  index  subtype,  the  X_SUBSCRIPT  exception  Is  raised.  The  result  is  a  variable  If  A 
is  a  variable. 

Subarrav  Selection 
The  result  of 

A<m1n. .max) 

where  A  is  a  1 -dimensional  array  and  the  type  of  min  and  max  is  the  Index  type  of  that  array,  Is  a 
subarray  of  A.  If  the  range  min  ..  max  is  non-empty  and  contains  an  index  outside  the 
array  bounds,  then  X_SUBSCRIPT  Is  raised.  The  result  has  the  same  component  type 
as  A.  The  index  subtype  of  the  result  Is  the  index  subtype  of  A  restricted  to 
the  range  min.  .max.  The  result  is  a  variable  if  A  is  a  variable. 
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C.8  STRING 


Subtype  Form 

STRING[S3< Ten) 

where  S  is  an  ENUM  subtype  and  ten  is  an  expression  with  type  INT. 

Values 

Character  strings  with  length  len.  Each  character  will  be  a  value  of  the  component  subtype  S.  If 
Ten  is  less  than  or  equal  to  zero  then  the  string  Is  empty. 

Literals:  All  string  literals. 


Purpose 

Operation 

Notes 

concatenate 

&( ENUM, ENUM )=>5TRING 

1,2 

concatenate 

&< ENUM, STRING) s >STRING 

1,2 

concatenate 

&(STRING,ENUM)=>STRING 

1,2 

concatenate 

&( STRING, STRING )=>STRING 

1,2 

equality 

s( STRING, STRING )=>B00L 

1,3 

ordering 

<( STRING, STRING)=>BOOL 

1,4 

assignment 

:=(STRING, STRING) 

1.5 

1)  Actual  parameters  must  have  the  same  type  or  have  an  ENUM  type  which  Is  the  same  as  the 
component  type  of  the  string. 

2)  The  length  of  the  result  is  the  sum  of  the  lengths  of  the  actual  parameters. 

3)  If  the  actual  parameters  have  a  different  length  then  the  result  is  false. 

4)  Ordering  is  based  on  ordering  of  the  type  of  the  characters.  Characters  are  compared  left  to 
right  with  characters  on  the  left  being  most  significant.  If  the  first  actual  parameter  is  a  prefix 
of  a  longer  second  parameter  the  result  is  true.  If  the  second  sctual  parameter  is  a  prefix  of  a 
longer  first  actual  parameter  then  the  result  Is  false. 

5)  Both  actual  parameters  must  have  the  same  length. 

Attribute  Inquiry 

Attribute  Result  Subtype  Result  Value 


STRINGCSIOen)  .LEN 


INTClen. . Ten) 


len 
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Component  Selection 
The  result  of 

V<  I> 

where  V  is  a  STRING  and  I  is  an  integer  whose  value  is  between  1  and  the  length  of  V,  is  the  Ith 
character  of  V.  If  I  is  out  of  bounds,  then  X_SUBSCRIPT  is  raised.  If  V  has  subtype  STRINGtSHn) 
then  the  result  has  subtype  S.  The  result  is  a  variable  if  V  is  a  variable.  The  result  of 

V<I..J) 

where  V  is  a  string  and  I  and  J  are  integers  whose  value  is  between  1  and  the  length  of  V  Is  a 
substring  of  V  starting  at  position  I  and  ending  at  position  J.  If  I  or  J  is  out  of  bounds,  then 
X_SUBSCRIPT  is  raised.  If  V  has  subtype  STRINGCS3(n)  then  the  result  has  subtype 
STRINGCSl  ( J-I+l ). 

C.9  SET 

Subtype  Form 

SETCS3 

where  S  is  an  INT  or  ENUM  subtype. 

Values:  Subsets  of  the  set  of  all  values  of  subtype  S. 

Operations 


Purpose  Operation  Notes 


equality  s(SET,SET)s>800L  1 

subset  <(5ET,SET)=>B00L  1 

membership  IN(  t.SETCt]  )=>B00L 

complement  NOT(SET)=>SET  2 

intersection  AND<SET,SET)=>5ET  1,2 

union  OR(SET,SET)=>SET  1,2 

symmetric  difference  XOR(SET,SET)=>SET  1,2 

assignment  :s(SET,SET)  1 


1)  Both  actual  parameters  must  have  the  same  subtype. 

2>  The  result  subtype  is  the  same  as  the  subtype  of  the  actual  parameter(s). 
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C.10  ACT 

Subtvoe  Form 
ACT 


Values  and  Components 


An  ACT  variable  is  used  to  control  the  elaboration  of  some  activation  and  contains  all  information 
needed  to  record  all  aspects  of  that  elaboration.  There  are  three  components  of  the  value  of  special 
interest  to  the  user. 

a)  A  state  -  which  has  three  subcomponents  as  follows 

1>  active  -  a  boolean.  All  ACT  variables  are  automatically  Initialized  to  be  Inactive  (i.e. 
active=false>. 

2)  waiting  -  a  boolean.  Initially  false. 

3>  suspended  -  a  boolean.  Initially  false. 

b)  A  priority  -  A  component  whose  subtype  is  INT(0..255>. 

c)  A  clock  -  This  measures  the  total  real  time  that  the  activation  has  been  running. 

Predefined  Constant:  NIL_ACT.  Representing  a  unique,  always  inactive  value. 


Operations 

Purpose 

current  activation 

active 

waiting 

suspended 

priority 

set  priority 

suspend 

unsuspend 


Operation  Notes 

* MEs>ACT  1 

•  ACTIVE ( AC  T ) = >B00L  2 

.  WAITING(ACT)=>BOOL  3 

SUSPENDED(ACT)=>BQOL  4 

*•  PRIORITY!  ACT)=>INT  5 

•SET_PRIORITY<ACT, INT)  6 

•SUSPEND(ACT)  7 

•UNSUSPEND(ACT)  8 


time 

• TIME( ACT)=>INT 

9 

delay 

♦DELAY_UNTIUACT,INY) 

10,11 

delay 

.  DELAY_UNTIL_INACTIVE(ACT) 

11,12 

wait 

'  / : 

•  0° 

'SYNC_WAIT  ( 

13 

reset 

-SYNC_RESET(  ) 

14 

signal 

-SYNC_SIGNAL(ACT> 

15 

create 

V. 

— TASK_START( ACT , ACT ) 

16 

finish 

. 

_-*-TASK_ENO(ACT) 

17 

low  level 

^  LOW_SYNC_WAIT 

18 

^LOW_SYNC_RESET 
^  L0W_S YNC_S IGNAL ( ACT ) 
^LOW_TASK_END(ACT) 

18 

18,19 

20 

terminate 

EXTERHINATE(ACT) 

21 

terminate  control 

CRITICAL 

22 
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NONCRITICAL  23 

assignment  :  =  (ACT,ACT)  24 

equality  *(ACT,ACT>=>B00L  25 

I)  Result  is  the  activation  variable  associated  with  the  invoking  activation. 

2>  Result  is  true  if  the  specified  activation  is  active. 

3)  Result  is  true  if  the  specified  activation  variable  is  active  and  waiting. 

4>  Result  is  true  if  the  specified  activation  variable  is  suspended. 

5>  Result  is  the  priority  of  the  specified  activation. 

6>  Sets  the  priority  of  the  specified  activation. 

7>  Sets  suspended  to  true. 

8)  Sets  suspended  to  false. 

9>  The  result  is  the  value  of  the  activation  clock  of  the  specified  activation  in  ticks. 

10>  Delays  until  the  activation  clock  of  the  specified  activation  is  greater  than  or  equal  to  the  time 
specified  in  ticks. 

II)  These  operations  can  be  used  as  waiting  invocations  in  the  wait  statement. 

12>  Waits  until  the  specified  activation  variable  is  inactive. 

13)  Equivalent  to  LOW_SYNC_WAIT  if  the  current  activation  was  created  with  an  ACT-type  activation 
variable,  or  to  SYNC_WAIT(av)  if  the  current  activation  was  created  with  activation  variable  av 
of  user-defined  type. 

14>  Equivalent  to  LOW_SYNC_RESET  or  SYNC_RESET(av)  depending  on  how  activation  a  was 
created. 

15)  Equivalent  to  LOW„SYNC_SIGNAL(a)  or  SYNC_SIGNAL(av)  depending  on  how  activation  a  was 
created. 

16)  Used  to  start  an  activation.  Called  as  part  of  the  elaboration  of  a  task  invocation  statement. 
Assigns  second  parameter  to  first. 

17>  Equivalent  to  LOW_TASK_END(a)  or  TASK_END(av)  as  in  (15). 

18)  LOW_SYNC_WAIT  sets  waiting  to  true  unless  LOW_SYNC_SIGNAL  has  been  called  for  this 
activation  since  L0W_SYNC_RE5ET  was  invoked. 

19)  Sets  waiting  to  false. 

20)  Invoked  when  an  activation  is  complete.  Can  also  be  used  to  terminate  some  other  task. 

21)  For  the  given  activation,  sets  waiting  to  false,  and  raises  the  ^-TERMINATE  exception. 

22)  Make  activation  critical. 

23)  Make  activation  noncritical. 

24)  This  is  a  sharing  assignment. 

25)  The  result  is  true  if  both  actual  parameters  are  the  same  activation  variable. 
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C.ll  MAILBOX 

Subtype  Form 

MAILBOXES]  den) 
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where  S  is  the  subtype  of  messages  and  len  is  an  integer  which  is  greater  than  or  equal  to  zero. 
Assignment  must  be  defined  for  the  type  of  S. 


Values  and  Components 

A  mailbox  can  hold  up  to  len  messages  having  subtype  S.  All  mailbox  variables  ere  automatically 
initialized  to  hold  no  messages.  Messages  are  queued  first-in  first-out. 


Operations 


Purpose 

send 
receive 
test  empty 
test  full 

conditional  send 
conditonal  receive 
low  level  ops 


assignment 

equality 


Qeerayeii„ 


5END(MAILB0XCt],  t) 
RECEIVE (MAILBOXCt 3, t) 

THprrstt 


INT 


FULL_SLOTS ( MAILBOX )*>INT 
C0ND_SEND 

{MAILBOXCt], fc, BOOL) 
COND.RECEIVE 
iHAXLBOXEt] , t,BOOL) 

SEND.ST 

SEND_REQUEST ( MAILBOXCt ] , t ) 
SEf»D_TEST<MAILBOXCt],t) 
SEND_COHPLETE 
(MAILBOXCt], t) 

SEND_REVOKE( MAILBOXCt] , t ) 
RECEIVE.ST 
RECEIVE_REQUEST 
(MAILBOXCt], t) 
RECEIVE_TEST(MAIL80XCt],  t) 
RECEIVE.COMPLETE 
(MAILBOXCt], t) 
RECEIVE_REVOKE 
(MAILBOXCt], t> 

:=(MAILB0X, MAILBOX) 
=(MAILB0X, MAILBOX) 


Notes 

1,2  "\ 

2,3  t 

4 

5 

6 

7 

8 
9 
9 

9 

9 

10 

11 

11 

11 

11 

12 

13 


n 


1)  Sends  a  message  to  a'  mailbox.  -Sender  waits  if  the  mailbox  is  full  until  the  mailbox  is  no  longer 
full.  If  there  are  several  waiting  senders  they  are  queued  first-in  first-out. 


2)  These  operations  can  be  used  as  waiting  invocations  in  the  wait  statement.  If  SEND  is  called  on 
a  zero  length  mailbox,  in  a  multi-way  wait  statement,  then  X_EMPTY_KAILBOX  is  called. 


3)  Receives  a  message  from  a  mailbox.  Receiver  waits  if  the  mailbox  is  empty  until  the  mailbox  Is 
no  longer  empty.  If  there  are  several  waiting  receivers,  they  are  queued  first-ln  first-out. 

4)  Count  of  empty  message  slots  plus  waiting  receivers. 

5)  Count  of  full  message  slots  plus  waiting  senders. 
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6>  Try  to  send;  indicate  success  as  a  returned  boolean  (true=success.  Never  wait. 

7)  Try  to  receive;  indicate  success  as  a  returned  boolean.  Never  wait. 

8)  Subtype  for  low-level  implementation  of  sends.  See  Section  14.3.1. 

9>  Operations  for  low-level  Implementation  of  sends. 

10)  Subtype  for  low-level  implementation  of  receives.  See  Section  14.3.1. 

11)  Operations  for  low-level  implementation  of  receives. 

12)  This  is  a  sharing  assignment. 

13)  The  result  is  true  if  both  actual  parameters  are  the  same  mailbox. 


Attribute  Inauirv 

Attribute 

Result  Subtvpe 

Result  Value 

MAILBOXtSK  len)  .LEN 

INT  < Ten. .Ten) 

Ian 

C.12  DATAJLQCK 

Subtvoe  Form 

DATA_LOCK 

Values  and  Components 

A  data  loch  is  either  locked  or  unlocked.  Ait  data  lock  variables  are  automatically  initialized  to  be 
unlocked.  If  a  data  iock  is  locked  it  has  an  owner,  which  is  the  activation  that  locked  it. 


Operations 

Purpose  Operation  Notes 


test  locked 
owner 
lock 
unlock 

conditional  lock 


EXCESS_LOCKS ( DATA_LOCK ) * >INT 
OWNER ( OATA_LOCK )  =  >ACT 
LOCK<DATA_LQCK)  2,3 

UNLOCK (DATA_L0CK>  1,3 

C0ND_L0CK ( DATA.L0CK , BOOL ) 


1)  If  not  locked,  raises  X_L0CK. 

2)  If  data  lock  is  unlocked  sets  the  data  lock  to  be  locked  and  the  owner  to  be  the  Invoking 
activation;  otherwise  the  Invoker  waits  until  the  data  lock  becomes  unlocked.  If  there  are 
several  activations  suspended  these  are  processed  on  a  first-come  first-served  basis. 

3)  These  are  low-level  operations  used  to  implement  user-defined  locking  operations  and  In  the 
implementation  of  the  REGION  statement. 
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C.13  LATCH 


The  LATCH  type  is  the  basic  low  level  synchronization  type. 


:  LATCH 


Values:  latched,  unlatched 


1)  Waits  until  the  actual  parameter  has  value  unlatched;  then  changes  the  value  to  latched  and 
continues.  If  several  tasks  are  waiting,  only  one  will  continue. 

2)  Changes  the  value  of  the  actual  parameter  to  unlatched. 

3)  The  second  parameter  is  a  status  result.  If  latch  has  the  value  unlatched,  then  performs  a  LOCK 
and  sets  result  to  true,  otherwise  sets  result  to  false. 
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C,14  FILE 

Subtype  Form 

FILE  CS]  (access,  use) 

Each  component  will  have  subtype  S.  Assignment  must  be  defined  for  the  type  of  S.  The  type  of 
access  must  be  ENUMt  'SEQ,  ‘RANDOM  ].  The  type  of  use  must  be  ENUHt  'INPUT,  'OUTPUT, 
'UPDATE  3. 

Values  and  Components 

A  file  variable  (also  called  a  file)  is  associated  with  an  ordered  sequence  of  components  each 
having  subtype  S.  The  components  will  reside  on  some  particular  physical  file  of  the  target  system. 
A  file  variable  is  associated  with  a  particular  physical  file  by  invocation  of  the  OPEN  procedure  (the 
file  is  then  said  to  be  open).  The  association  is  broken  by  invocation  of  the  CLOSE  procedure  (the  file 
is  then  said  to  be  closed).  Initially  all  flies  are  closed. 

The  access  of  a  file  determines  how  the  components  are  accessed. 

'SEQ  sequential  access 

'RANDOM  random  access 

The  use  of  a  file  determines  how  the  file  will  be  used. 

'  INPUT  components  are  read  but  not  written. 

'OUTPUT  components  are  written  but  not  read. 

'UPDATE  components  are  both  written  and  read. 

When  a  file  is  open  it  has  a  size  which  is  the  number  of  components  in  the  file  and  a  position  which  Is 
an  integer  whose  value  is  greater  than  or  equal  to  l  and  which  is  less  than  or  equal  to  the  size  of  the 
file  plus  1.  Position  1  is  before  all  components  in  the  file.  Position  2  is  before  the  second  component, 
etc. 
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Operations 


Purpose 

Operation 

Notes 

open 

OPEN(FILE, STRING, 

ENUMt'OLD),  'NEW] 

1,2 

close 

CLOSEFILE, 

ENUMC  'SAVE,  'DELETED 

3,4 

size 

SIZE(FILE)=>INT 

3,5,6,15 

position 

POSITION(FILE)=>INT 

3,7,15 

set  position 

SET_P05ITI0N(FILE, INT> 

3,5,3 

end  of  file 

EOF(FILE)=>BOOL 

3,9,15 

read 

READ(FILE.t) 

3,10,11,12 

write 

WRIT£(FILE,t) 

3,11,13,14 

read  line 

READLN(FILE, STRING) 

15,16,17 

write  line 

WRITELN(FILE, STRING) 

16,18 

line  size 

SIZELN(FILE)=>INT 

15,16,19 

read  line 

READLN(STRING) 

15,20 

write  line 

WRITELN(STRING) 

21 

size  line 

SIZELNt )=>INT 

15,23 

eof 

EOFO 

15,22 

other 

see  note 

24 

1)  Raises  X_FILE  if  file  is  already  open. 

2)  The  string  specifies  the  physical  file  with  which  the  file  variable  is  to  be  associated.  The 
interpretation  of  the  string  is  implementation-dependent.  If  there  is  no  such  device  or  physical 
file  then  the  X_FILENAME  exception  is  raised.  The  enumeration  value  specifies  whether  an 
existing  file  is  to  be  used  ('OLD)  or  a  new  file  is  to  be  created  ('NEW).  If  for  'OLD  there  is  no 
existing  physical  file  then  the  X..N0FILE  exception  is  raised.  The  position  of  the  file  is  set  to  1. 
A  'NEW  file  initially  has  size  0 

3)  Raises  X_FILE  if  file  is  not  open. 

4)  The  enumeration  value  'SAVE  indicates  that  the  physical  file  is  to  be  saved  for  use  by  latter 
programs.  The  value  'DELETE  indicates  that  the  physical  file  is  not  be  saved.  The  current 
position  is  taken  as  the  new  end  of  file. 

5)  These  procedures  and  functions  may  not  be  available  for  all  physical  files.  If  not,  the  X_FH-E 
exception  is  raised.  They  will,  however,  always  be  available  for  'RANDOM  access  files. 

6)  Returns  the  size  of  the  file. 

7)  Returns  the  current  position. 

8)  This  procedure  repositions  the  file  to  the  specified  new  position.  If  the  integer  parameter  Is 
less  than  1  or  greater  than  the  size  of  the  file  +1  then  the  X_FILEPOS  exception  Is  raised. 

9)  Returns  true  if  the  position  of  the  file  is  equal  to  the  size  of  the  file  +1. 

10)  Legal  only  if  use  is  'INPUT  or  'UPDATE.  Otherwise,  X..FILE  is  raised. 

1 1 )  The  second  parameter  must  have  the  same  type  as  the  components  of  the  file. 

12)  The  component  following  the  current  position  is  assigned  to  the  second  parameter.  The  current 
position  is  incremented  by  one.  If  EOF  is  true,  then  the  X_E0F  exception  is  raised. 

13)  If  EOF  is  true  prior  to  the  invocation,  then  the  number  of  components  in  the  file  is  increased  by 
one.  The  component  following  the  current  position  is  assigned  the  value  of  the  second 
parameter.  The  current  position  is  Incremented  by  one. 
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14)  Legal  only  if  use  is  'OUTPUT  or  'UPOATE.  Otherwise  X_FILE  is  raised. 


15)  These  are  abnormal  functions  <see  ). 


16)  The  file  type  must  be  FILEtENUMt ...]].  The  ENUM type  must  Include  'CRand  'LF. 


17)  REAOLN  reads  components  until  a  'CR  followed  by  a 
'CR  'LF  are  returned  as  characters  in  the  string, 
found  or  if  the  string  is  of  the  wrong  length. 


'LF  is  found.  All  components  prior  to  the 
Raises  X_LN  if  no  'CR  followed  by  'LF  is 


18)  Writes  each  character  in  the  string  as  a  component  In  the  file  and  then  writes  a  'CR  followed 
by  a  'LF. 

19)  Returns  the  number  of  characters  between  the  current  position  and  the  position  Immediately 
before  the  next  'CR  followed  by  'LF. 


20)  READLNJs)  is  equivalent  to  READLN(SYS_IN,s). 

21)  WRITELJKs)  is  equivalent  to  WRITELN(SYS_OUT,s). 


22)  EOF  is  equivalent  to  EOF(SYS_IN). 

23)  SIZELN  is  equivalent  to  SIZELN(SYS_IN). 

24)  It  is  anticipated  that  a  variety  of  implementation-dependent  and/or  device-dependent  routines 
will  be  available  for  setting  and  interrogating  file  characteristics  such  as  protection,  physical 
blocking,  and  file  space. 


Attribute  Inquiry 
Attribute 

FILEtSKaccess,  use). ACCESS 
FILE[S](access,  use). USE 


Result  Subtype  Result  Valuer 

ENUMC'SEQ,  'RANDOM]  access 

ENUMt' INPUT,  'OUTPUT,  use 
•UPDATE] 
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C.15  ASCI! 

The  128  character  ASCII  character  set  is  a  lanRuaRe  defined  abbreviation.  Its  definition  appears 
below. 


ABBREV  ASCII 

:  ENUMC 

'NUL, 

X  00 

null 

•SOH, 

X  01 

start  of  heading 

•STX, 

X  02 

start  of  text 

'ETX, 

X  03 

end  of  text 

'EOT, 

X  04 

end  of  transmission 

•ENQ, 

X  05 

enquiry 

•ACK, 

X  06 

acknowledge 

'BEL, 

X  07 

bell 

'BS, 

X  08 

backspace 

'HT, 

X  09 

horizontal  tabulation 

'IF, 

X  0A 

line  feed 

'VT, 

X  08 

vertical  tabulation 

'FF, 

X  0C 

form  feed 

•CR, 

X  0D 

carriage  return 

'SO, 

X  0E 

shift  out 

•si, 

X  0F 

shift  In 

•DLE, 

X  10 

data  link  escape 

'DC1, 

X  11 

device  control  1 

'DC2, 

X  12 

device  control  2 

'DC3, 

X  13 

device  control  3 

'DC4, 

X  14 

device  control  4 

'NAK, 

X  15 

negative  acknowledge 

•SYN, 

X  16 

synchronous  idle 

'ETB, 

X  17 

end  of  transmission  block 

•CAN, 

X  18 

cancel 

'EM, 

X  19 

end  of  medium 

'SUB, 

X  'A 

substitute 

'ESC, 

X  IB 

escape 

'FS, 

X  1C 

file  separator 

'GS, 

X  ID 

group  separator 

•RS, 

X  IE 

record  separator 

'US, 

X  IF 

unit  separator 

'SP 

X  20  blank 

space  (normally  non-printing) 

'EXCLAIM, 

X  21  ! 

exclamation  point 

'QUOTE, 

X  22  * 

quotation  marks 

'NUMBER, 

X  23  # 

number  sign 

'DOLLAR, 

X  24  S 

dollar  sign 

' percent; 

X  25  X  ’ 

percent 

'AMPERSAND, 

X  26  & 

ampersand 

'APOS, 

X  27  ' 

apostrophe 

'LPAREN, 

X  28  ( 

opening  parenthesis 

•RPAREN, 

X  29  ) 

closing  parenthesis 

'STAR, 

X  2A  * 

asterisk 

'PLUS, 

X  2B  + 

plys 

'COMMA, 

X  2C  , 

comma 

'MINUS, 

X  2D  - 

hyphen  (minus) 

•PERIOD, 

X  2E  . 

period 

•SLASH, 

X  2F  / 

slant 

'N_0 , 

X  30  0 

JN_1, 

X  31  1 

■ 

'N_2, 

X  32  2 

'H_3, 

X  33  3 

INTERMETRICS  INC. 


Appendix  C.15 


245 


N_4, 

X 

34 

4 

N_5, 

X 

35 

5 

N_6, 

X 

36 

6 

N_7, 

X 

37 

7 

N_8, 

X 

38 

8 

N_9, 

% 

39 

9 

COLON, 

X 

3A 

• 

• 

colon 

SEMI, 

X 

3B 

• 

» 

semicolon 

LESS, 

X 

3C 

< 

less  than 

EQUAL, 

X 

3D 

= 

equals 

GREATER, 

X 

3E 

> 

greater  than 

QUESTION, 

X 

3F 

? 

question  mark 

AT, 

X 

40 

0 

commercial  at 

A, 

X 

41 

A 

B, 

X 

42 

B 

•  • 

z. 

X 

5A 

z 

LBRACKET, 

X 

5B 

C 

opening  bracket 

BSLASH, 

X 

5C 

\ 

reverse  slant 

RBRACKET, 

X 

50 

] 

closing  bracket 

CIRCUMFLEX, 

X 

5E 

A 

circumflex 

UNDERSCORE, 

X 

5F 

underline 

GRAVE, 

X 

60 

\ 

grave  accent 

1 — A, 

X 

61 

a 

L_B, 

X 

62 

b 

•  • 

1 — z, 

% 

7A 

z 

LBRACE, 

X 

7B 

{ 

opening  brace 

BAR, 

X 

7C 

I 

vertical  line 

RBRACE, 

X 

7D 

} 

closing  brace 

TILDE, 

X 

7E 

- 

overllne  (tilde) 

DEL  „ 

X 

7F 

delete 

I 

j 

( 

» 
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D.  EXCEPTIONS 


Exception 

X__ASSERT 

X.CASE 

X_EMPTY_MAILBOX 

X_EOF 

X_FILE 

X_FILENAME 

X_FILEPOS 

X_FREE 

X_INIT 

X_LN 

X_LOCK 


Raised  When 
Assertion  is  false 

No  case  value  label  or  else  clause  matching  case  expression  value 
Attempt  to  define  zero  length  mailbox 
Attempt  to  read  past  cof 

File  processing  attempted  on  unopen  file,  file  processing  routine  not  available  for 
file,  routine  not  available  for  file,  or  attempt  to  wait  on  input  file  or  read  output 
file 

Physical  file  name  unknown 
Attempt  to  position  outside  of  file 

Attempt  to  free  space  for  dynamic  variable  still  referenced  by  Indirect  variable 
Attempt  to  access  uninitialized  variable 
'CR  not  followed  by  'LF 

Attempt  to  unlock  data-lock  which  already  is  unlocked  or  attempt  to  find  owner  of 
unlocked  data-lock 


X_MAXRANGE 
X_NEG_EXP 
X_NOFILE  * 

.  X_OVERFLOW 
X_RANGE 
X_SUBSCRIPT 
X_SUBTYPE 
X_TAG 

X_UNHANDLED 

X_ZERO_DIVIDE 


Value  is  outside  of  implementation-defined  largest  range 
Attempt  to  raise  a  number  to  a  negative  power 
Designation  of  nonexistent  file  as  'OLD 

Result  of  operation  is  outside  of  implementation-selected  range  for  INT  or  FLOAT 
Source  value  is  not  valid  for  the  target  (ENUM,  INT,  FLOAT) 

Attempt  to  access  beyond  ARRAY  or  STRING  bounds 

Attempt  to  pass  actual  of  different  subtype  to  VAR  or  READONLY  formal  parameter 
Selection  of  UNION  component  not  currently  present 
Exception  has  not  been  handled  when  completing  its  scope 
Attempt  to  divide  INT  or  FLOAT  by  zero 
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E.  GLOSSARY 

abbreviation 

shorthand  notation  for  type  or  subtype  specification, 
abnormal  function 

a  function  upon  which  common  subexpression  elimination  may  not  be  performed, 
access  method 

sequential  or  random  file  access, 
active  activation  variable 

an  activation  variable  associated  with  a  specific  activation. 

activation 

an  elaboration  of  a  task  which  can  occur  concurrent  with  other  activations, 
activation  clock 

measures  total  real  time  that  a  particular  activation  has  run. 

activation  variable 

means  for  'naming'  an  activation. 

aetual  parameter 

expression  in  an  invocation,  bound  to  formal  parameter  in  declaration  of  the  Invoked 
deferred  unit. 

assignable  types 

those  types  for  which  assignment  <:=)  is  defined. 

allocation  statement 

creates  a  dynamic  variable. 

attributes 

subtype  constraints, 
available  definitions 

for  an  open  scope,  all  definitions  known  in  the  immediately  enclosing  scope.  Ft  a  closed 
scope,  all  definitions,  except  variable,  goto  label,  and  matching  identifier  definitions,  from  the 
immediately  enclosing  scope,  together  with  all  imported  definitions. 

binding 

association  of  actual  with  formal  parameters. 

body 

possibly  empty  sequence  of  declarations,  assertions,  and  statements, 
closed  scope 

scope  which  is  similar  to  open  scope,  except  that  variable  definitions  only  become  available 
by  being  imported. 

compound  statement  or  declaration 

statement  or  declaration  containing  a  body. 

conditional  translation 

selection,  during  translation,  between  alternative  bodies  or  selection  of  a  single  union 
component  to  be  present 

conflicting  definitions 

definitions  of  the  same  name  among  which  a  use  of  the  name  cannot  discriminate. 

constant 

data  item,  having  a  subtype,  whose  value  cannot  be  modified, 
constructor 

way  of  building  a  value  of  a  record,  union,  array,  or  user-defined  type. 


dangerous  sharing 

non-orderly  use  of  a  shared  variable. 

declaration 

one  form  of  language  construct  used  for  defining  a  name, 
deferred  declaration 

a  declaration  which  is  elaborated  when  invoked,  not  when  encountered, 
deferred  unit 

the  entity  defined  by  a  deferred  declaration. 

definition 

any  way  of  associating  a  name  with  a  language  construct. 

delaying 

non-busy  waiting  of  an  activation  upon  a  clock  value. 

data  item 

defined  variables  and  constants,  dynamic  variables,  readonly  data  items  and  temporary  data 
items. 

dot  selection 

qualification  to  obtain  component  of  record  or  union.  Also  used  to  dereference  pointers, 
dynamic  variable 

the  variable  pointed  to  be  an  indirect  variable  or  constant, 
elaboration 

the  action  required  at  translation  time  and  runtime  to  cause  statement  execution,  expression 
evaluation,  and  declaration  processing. 

exception 

an  exceptional  condition  which  can  be  raised  and  handled, 
explicit  overloading 

overloading  which  occurs  by  writing  two  definitions  of  the  same  name  with  different 
interfaces. 

exported  definitions 

definitions  local  to  a  capsule  which  may  be  made  known  outside  the  capsule. 

exposing 

making  exported  names  of  a  capsule  known, 
extermination 

raising  X_TERMINATE  in  another  activation, 
external  capsule 

a  capsule  which  was  separately  translated, 
file 

a  variable  of  a  FILE  type  which  is  associated  with  an  ordered  collection  of  components,  all 
having  the  same  type. 

file  use 

input,  output,  or  update  files, 
flow  diagrams 

syntactical  description  technique, 
formal  parameter 

placeholder  within  a  deferred  declaration, 
generic  constraint 

restricts  the  set  of  replacement  elements  which  may  be  associated  with  a  particular  generic 
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parameter, 
generic  overloading 

overloading  which  occurs  when  a  deferred  declaration  is  replicated  generlcally. 
generic  parameter 

placeholder  within  a  generic  declaration, 
generated  set 

all  definitions  created  as  a  result  of  a  generic  declaration. 

goto  label 

used  only  as  target  of  goto  statement, 
guarded  body 

body  of  a  guard  statement  in  which  an  exception  might  be  raised  and,  so,  Is  protected. 

handler 

part  of  a  guard  statement  which  specifies  a  body  to  be  elaborated  if  a  specific  exception  Is 
raised  during  elaboration  of  the  guarded  body. 

handling  an  exception 

terminating  the  guarded  body  in  which  the  exception  Is  raised  and  attempting  to  find  a 
handler  for  the  exception. 

immediate  declaration 

a  declaration  which  is  elaborated  when  encountered, 
imported  definitions 

variable  definitions  which  become  available  to  closed  scopes  through  an  imports  list. 

inactive  activation  variable 

an  activation  variable  associated  with  no  activation. 


index 

counter  for  repeat  statement. 

indirect  variable  or  constant 
typed  pointer. 

infix  operator 

operator  <**,  *,  /,  MOD,  DIV,  &,  +,  =,  /=,  <,  <*,  >,  >=,  IN,  AND,  OR,  XOR>  which  takes  two 

operands. 


initialization 

assigning  a  first  value  to  a  data  item. 

inquiry 

operations  which  interrogate  the  type,  subtype,  or  attributes  of  data  Items. 

interface 

information,  contained  in  both  definitions  and  uses  of  overloaded  names,  which  is  used  to 
associate  a  use  with  a  single  definition. 

known  in  a  scope 

all  definitions  which  can  be  associated  with  a  use  of  a  name  within  a  scope.  Includes  all 
local  definitions  plus  all  non-conflicting  available  definitions. 

lifetime 

the  span  of  execution  time  that  a  construct  exists. 


literal 

token  used  to  specify  a  value  of  a  built-in  or  user-defined  type, 
local  definitions 

all  definitions  either  defined  in  a  scope  or  exposed  into  it  by  a  capsule  Invocation. 
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mailbox 

queue  of  messages  used  for  inter -activation  communication, 
manifest  expression 

expression  which  is  elaborated  during  translation, 
matching  identifier 

used  for  documentation  and  as  target  of  exit  statement, 
message  passing 

transmittal  of  messages  between  activations  by  means  of  mailboxes, 
mutual  exclusion 

orderly  access  to  shared  variables  accomplished  via  the  region  statement. 

name 

an  identifier  or  definable  symbol  associated  with  defined  language  constructs, 
needed  name 

a  name  which  appears  in  a  generic  declaration  and  is  bound  at  point  of  invocation  rather 
than  point  of  generic  declaration. 

new  capsule 

a  capsule  whose  invocation  results  in  the  elaboration  of  the  capsule  (and  therefore  creation 
of  separate  copies  of  local  data). 

new  type 

type,  defined  by  type  declaration,  distinct  from  all  other  types, 
normal  function 

a  function  upon  which  common  subexpression  elimination  may  be  done, 
old  capsule 

a  capsule  whose  invocation  does  not  result  in  elaboration  of  the  capsule, 
open  scope 

scopes  following  normal  block-structured  rules, 
overloading 

association  of  a  single  name  with  multiple  deferred  units  of  the  same  kind. 

own  data 

data  local  to  a  capsule, 
pattern  declaration 

the  deferred  declaration  which  is  generically  replicated, 
physical  file 

a  file  on  a  storage  medium,  a  physical  device,  or  a  file  on  a  storage  medium  representing  a 
physical,  device. 

precedence 

for  operators,  the  relative  strength  of  operand  association, 
prefix  operator 

operator  (+,  NOT)  which  takes  only  a  single  operand. 

primary 

expression  operand. 

priority 

absolute  (rather  than  relative)  importance  of  an  activation, 
raising  an  exception 

causing  the  occurrence  of  an  exceptional  condition  which  may  be  handled  by  a  guard 
statement. 
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random  file 

a  file  which  permits  direct  access  to  any  component,  regardless  of  Its  position  with  respect 
to  other  components. 


range 

a  contiguous  sequence  of  values  of  some  type, 
readonly  data  item 

variable  whose  use  is  restricted  to  access  only  in  some  contexts  but  which  may  still  be 
modified  in  other  contexts. 

real-time  clock 

measures  elapsed  real-time  since  program  began  to  run. 

renaming 

changing  of  a  name  through  a  capsule  invocation, 
replacement  element 

the  item  which  appears  in  an  invc  atlon  and  is  substituted  for  the  corresponding  generic 
parameter  in  the  definition. 

result  type  or  subtype 

type  or  subtype  of  function  result. 

routine 

procedure,  function,  or  operator. 

scheduler 

determines  which  activation  will  next  run.  The  built-in  priority  scheduler  may  be  replaced 
with  a  user-defined  scheduler. 

sequential  file 

file  which  is  processed  by  accessing  each  component  In  succession, 
shared  variable 

a  variable  which  is  accessible  to  multiple  activations, 
side-effect 

modification  of  data  by  a  function  when  the  lifetime  of  the  data  is  longer  than  the  lifetime  of 
the  function  invocation. 

signature 

number,  order,  and  types  of  parameters.  Part  of  interface. 

slice 

contiguous  components  contained  within  one  dimensional  array. 

standard  fiie  * 

a  file  whose  components  do  not  have  an  enumeration  type. 

state  of  a  file 

initial  state  (old  or  new)  and  final  disposition  (save  or  delete), 
subscripting 

qualification  to  obtain  component  of  array  or  array  slice. 

subtype 

translation  time  and  runtime  properties  of  a  data  item, 
subtype  constraints 

round-bracketed  information  of  subtype  which  can  be  left  unresolved  until  runtime, 
temporary  data  item 

data  item  whose  lifetime  is  tied  to  its  use  rather  than  to  a  scope.  Includes  the  result  of 
literals,  constructors,  functions,  and  attribute  inquiry. 
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text  file 

a  file  whose  components  have  an  enumeration  type, 
translation  time  property  list 

part  of  the  interface  of  deferred  declarations  used  for  resolving  name  conflicts. 


type 

translation  time  properties  of  a  data  item. 


type  and  subtype  resolution 

determination  of  type  and  subtype  of  expression. 

type  checking 

verifying,  at  translation  time,  that  two  types  are  the  sdme. 
underlying  subtype 

subtype  specification  used  to  define  a  new  type. 

underlying  type 

type  of  underlying  subtype. 


underlying  variable  or  constant 

representation  (obtained  by  .ALLt  of  variable  or  constant  of  a  new  type.  An  underlying 
variable  may  also  be  the  dynamic  variable  pointed  to  by  an  indirect  variable  or  constant. 


value  labels 

labels  of  case  statement. 


variable 

data  item,  having  a  subtype,  whose  value  can  be  modified.  Includes  defined  and  dynamic 
variables. 

visible  definitions 

definitions  which  are  exported  from  a  capsule  and  exposed  by  s  capsule  invocation. 

waiting 

non-busy  suspension  of  an  activation  until  some  event  occurs. 
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F.  diagram  cross  reference 

DIAGRAM  CROSS-REFERENCE 
(alphabetical ly) 


LEXICAL  SYNTAX  DIAGRAMS 

Diagram  Section 

Identifier  Number 

2.3.9 

2.4.1 

2.3.7 
2.3.6 

2.3.4 

2.3.10 
2.3.6 

2.3.5 

2.4.2 

2.3.8 

2.2 
2.2 


(by  diagram  identifier) 


boo  I ean  I  i tera I 
comment 
enum  I i tera I 
float  I i tera I 
identi f ier 
i nd i rect  I  i tera I 
i nt  I  i  tera I 
I i teral 

pragmat  token  separator 

str i ng  I i tera I 

token 

token  separator 


1 

K 

G 

F 

C 

J 

E 

D 

L 

H 

A 

B 

DIAGRAM  CROSS-REFERENCE 


LEXICAL  SYNTAX  DIAGRAMS 

Diagram  Section 

Identifier  Number 


token 

token  separator 
i dent i f i er 
I i teral 
int  I i teral 
float  I  i-teral 
enum  literal 
str i ng  I  i tera I 
boo  I ean  I  i teral 
indirect  literal 
comment 

pragmat  token  separator 


A 

B 

C 

D 

E 

F 

G 

H 

I 

J 

K 

L 


2.2 

2.2 

2.3.4 

2.3.5 

2.3.6 

2.3.6 

2.3.7 

2.3.8 

2.3.9 

2.3.10 

2.4.1 

2.4.2 


♦ 


11 
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GRAMMAR  SYNTAX  DIAGRAMS 


Diagram  Section 

Identifier  Number 


abbreviation  declaration 

17 

4.4.1 

abbreviation  invocation 

18 

4.4.1 

actual  parameters 

53 

7.3 

actual  translation  time  properties 

67 

11.1.2 

allocation  statement 

24 

4.4.3 

array  constructor 

33 

5.6 

a9ser  t i on 

8 

3.4 

assignment  statement 

40 

6.1 

attribute  inquiry 

25 

4.5.3 

begin  statement 

41 

6.2 

body 

2 

3.2 

body  element 

i 

3.2 

capsule  declaration 

54 

8.1 

capsule  invocation  declaration 

55 

8.1 

case  statement 

43 

6.4 

compound  declaration 

7 

3.3 

compound  statement 

39 

6 

constant 

29 

5.3 

constant  declaration 

16 

4.2.1 

constructor 

31 

5.6 

dec  1 arat i on 

4 

3.3 

deferred  declaration 

6 

3.3 

definable  symbol 

81 

13.1 

direct  type  declaration 

20 

4.4.2 

exception  declaration 

57 

9.1 

exit  statement 

45 

6.6 

expression 

26 

5.2 

formal  parameters 

52 

7.3 

formal  translation  time  properties 

66 

11.1.2 

function  declaration 

50 

7.2 

function  invocation  primary 

51 

7.2 

generic  constraint 

71 

11.3 

generic  declara  ion 

69 

11.3 

generic  parameters 

70 

11.3 

goto  statement 

47 

6.8 

guard  statement 

58 

3.2 

if  statement 

42 

6.3 

immediate  declaration 

5 

3.3 

imports 

9 

3.7 

indirect  type  declaration 

23 

4.4.3 

location  specification 

80 

12.3 

needed  i tem 

77 

11.4 

needs 

76 

11.4 

operation  generic  constraint 

74 

11.3.3 

pragmat 

83 

B 

pragmats 

82 

B 

pr 1 mary 

27 

5.3 

procedure  declaration 

48 

7.1 
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procedure  invocation  statement 

raise  statement 

range 

record  or  union  constructor 

referencing  form 

region  statement 

repeat  statement 

representat i ona I  item 

representational  specification 

reraise  statement 

resolved  constant 

return  statement 

set  constructor 

simple  statement 

statement 

subtype 

subtype  comparison 

subtype  generic  constraint 

task  declaration 

task  invocation  statement 

translation  time  property 

trans I  at i on  uni t 

type 

type  compar i son 
type  declaration 
type  generic  constraint 
un labeled  statement 
user-defined  subtype 
user-defined  type 
value  generic  constraint 
var i ab I e 

variable  declaration 
visible  1 i 3 1 
uait  statement 
uaiting  invocation 


49 

7.1 

59 

9.3 

14 

4.1.7 

32 

5.6 

30 

5.3 

G5 

i0.7 

44 

6.5 

79 

12.2 

78 

12.2 

60 

9.4 

35 

5.7 

46 

6.7 

34 

5.6 

38 

6 

36 

6 

12 

4.1.6 

13 

4.1.6 

73 

11.3.2 

61 

10.1 

62 

10.1 

68 

11.1.2 

1 

3.1 

10 

4.1.5 

11 

4.1.5 

19 

4.4.2 

72 

«  «  «  4 

H  i  O.  A 

37 

6 

22 

4.4.2 

21 

4.4.2 

75 

11.3.4 

28 

5.3 

15 

4.2.1 

56 

8.2 

63 

10.5 

64 

10.5 
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D 1 AGRAM  CROSS-REFERENCE 
(by  diagram  identifier) 


GRAMMAR  SYNTAX  DIAGRAMS 


Diagram 

Section 

I  dent i f i sr 

Number 

trans 1  at i on  unit 

1 

3.1 

body 

2 

3.2 

body  element 

3 

3.2 

dec  1 arat i on 

4 

3.3 

immediate  declaration 

E 

3.3 

deferred  .declaration 

G 

3.3 

compound  declaration 

7 

3.3 

asser t i on 

8 

3.4 

i mpor  te 

3 

3.7 

type 

IB 

4.1.5 

type  comparison 

11 

4.1.5 

subtype 

12 

4.1.G 

subtype  comparison 

13 

4.1.G 

range 

14 

4.1.7 

variable  declaration 

15 

4.2.1 

constant  declaration 

1G 

4.2.1 

abbreviation  declaration 

17 

4.4.1 

abbreviation  invocation 

18 

4.4.1 

type  declaration 

13 

4.4.2 

direct  type  declaration 

20 

4.4.2 

user-defined  type 

21 

4.4.2 

user-defined  subtype 

22 

4.4.2 

indirect  type  declaration 

23 

4.4.3 

allocation  statement 

24 

4.4.3 

attribute  inquiry 

25 

4.5.3 

express i on 

2G 

5.2 

pr i mary 

27 

5.3 

var i ab 1 e 

28 

5.3 

constant 

29 

5.3 

referencing  form 

30 

5.3 

constructor 

31 

5.G 

record  or  union  constructor 

32 

5.G 

array  constructor 

33 

5.G 

set  constructor 

34 

5.6 

resolved  constant 

35 

5.7 

statement 

3G 

G 

un labeled  statement 

37 

6 

simple  statement 

38 

6 

compound  statement 

39 

6 

assignment  statement 

40 

G.l 

begin  statement 

41 

6.2 

if  statement 

42 

G.3 

case  statement 

43 

G.4 

repeat  statement 

44 

G.5 

exit  statement 

45 

6.6 

return  statement 

4G 

6.7 

goto  statement 

47 

6.8 

procedure  declaration 

‘3 

7.1 
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procedure  invocation  statement 

49 

7.1 

function  declaration 

50 

7.2 

function  invocation  primary 

51 

7.2 

formal  parameters 

52 

7.3 

actual  parameters 

53 

7.3 

capsule  declaration 

54 

8.1 

capsule  invocation  declaration 

55 

8.1 

visible  list 

56 

8.2 

exception  declaration 

57 

9.1 

guard  statement 

58 

9.2 

raise  statement 

59 

9.3 

reraise  statement 

60 

9.4 

task  declaration 

61 

10.1 

task  invocation  statement 

62 

10.1 

wait  statement 

63 

10.5 

waiting  invocation 

64 

10.5 

region  statement 

65 

10.7 

formal  translation  time  properties 

66 

11.1.2 

actuai  translation  time  properties 

67 

11.1.2 

translation  time  property 

68 

11.1.2 

generic  declaration 

69 

11.3 

generic  parameters 

70 

11.3 

generic  constraint 

71 

11.3 

type  generic  constraint 

72 

11.3.1 

subtype  generic  constraint 

73 

11.3.2 

operation  generic  constraint 

74 

11.3.3 

value  generic  constraint 

75 

11.3.4 

needs 

76 

11.4 

needed  i tern 

77 

11.4 

representational  specification 

78 

.12.2 

representational  item 

79 

12.2 

location  specification 

80 

12.3 

definable  symbol 

81 

13.1 

pragma ts 

82 

B 

pragmat 

83 

B 
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DIAGRAM  CROSS-REFERENCE 
(alphabetical ly) 


XREF  OF  LEXICAL  NAMES 


Diagram 

Section 

Identifier 

Number 

boolean  1  i  teral 

1 I teral 

D 

2.3.5 

comment 

token  separator 

B 

2.2 

enum  literal 

1 i tera 1 

D 

2.3.5 

type 

10 

4.1.5 

float  1 \ teral 

1 i teral 

D 

2.3.5 

Identi f ier 

abbreviation  declaration 

17 

4.4.1 

abbreviation  invocation 

18 

4.4.1 

attribute  inquiry 

25 

4.5.3 

capsule  declaration 

54 

8.1 

capsule  invocation  declaration 

55 

8.1 

constant  declaration 

IB 

4.2.1 

definable  symbol 

81 

13.1 

direct  type  declaration 

20 

4.4.2 

enum  1 i tera 1 

G 

2.3.7 

exception  declaration 

57 

9.1 

exit  statement 

45 

G.G 

formal  parameters 

52 

7.3 

function  declaration 

58 

7.2 

function  invocation  primary 

51 

7.2 

generic  parameters 

70 

11.3 

goto  statement 

47 

B.8 

guard  statement 

58 

9.2 

i mpor ts 

9 

3.7 

indirect  type  declaration 

23 

4.4.3 

needed  i tem 

77 

11.4 

procedure  declaration 

48 

7.1 

procedure  invocation  statement 

49 

7.1 

raise  statement 

59 

9.3 

record  or  union  constructor 

32 

5.6 

referencing  form 

30 

5.3 

repeat  statement 

44 

6.5 

representational  item 

79 

12.2 

statement 

36 

6 
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subtype 

subtype  generic  constraint 
task  declaration 
task  invocation  statement 
token 

translation  time  property 
type 

type  generic  constraint 
unlabeled  statement 
user-defined  subtype 
user-defined  type 
variable  declaration 
visible  list 
waiting  invocation 


12 

73 

B1 

62 

A 

68 

10 

72 

37 

22 

21 

15 

56 

64 


indirect  I i teral 
I i tera I 


D 


int  literal 
I i teral 


D 


I  i tera I 

constant  29 

token  A 


pragmat  token  separator 


str i ng  I i teral 

I i tera I  D 


token 


token  separator 


I 


4.1.6 

11.3.2 
10.1 
10.1 

2.2 
11.1.2 

4.1.5 

11.3.1 
6 

4.4.2 

4.4.2 

4.2.1 

8.2 

10.5 


2.3.5 


2.3.5 


5.3 

2.2 


2.3.5 
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DIAGRAM  CROSS-REFERENCE 
(alphabetical ly) 


XREF  OF  SYNTACTIC  NAMES 

Diagram  Section 
Identifier  Number 


abbreviation  declaration 


deferred  declaration 

6 

3.3 

abbreviation  invocation  ■ 

subtype 

12 

4.1.6 

type 

18 

4.1.5 

actual  parameters 

abbreviation  invocation 

18 

4.4.1 

allocation  statement 

24 

4.4.3 

capsule  invocation  declaration 

55 

8.1 

function  invocation  primary 

51 

7.2 

procedure  invocation  statement 

49 

7.1 

task  invocation  statement 

G2 

10.1 

t  user-defined  aubtype 

22 

4.4.2 

actual  translation  time  properties 

abbreviation  invocation 

18 

4.4.1 

capsule  invocation  declaration 

55 

8.1 

function  invocation  primary 

51 

7.2 

procedure  invocation  statement 

49 

7.1 

task  invocation  statement 

B2 

10.1 

translation  time  property 

68 

11.1.2 

user-defined  subtype 

22 

4.4.2 

user-defined  type 

21 

4.4.2 

allocation  statement 

simple  statement 

38 

6 

array  constructor 

constructor 

31 

5 

assertion 

body  element 

3 

3.2 

assignment  statement 

simple  statement 

38 

6 
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attribute  inquiry 

constant  29  5.3 

begin  statement 

compound  statement  39  G 

body 

begin  statement  41  8.2 

capsule  declaration  54  8.1 

case  statement  43  G.4 

function  declaration  50  7.2 

guard  statement  58  9.2 

if  statement  42  G.3 

procedure  declaration  48  7.1 

region  statement  G5  10.7 

repeat  statement  44  G.5 

task  declaration  61  10.1 

wait  statement  63  10.5 

body  element 

body  2  3.2 

capsule  declaration 

compound  declaration  7  3.3 

translation  unit  1  3.1 

capsule  invocation  declaration 

immediate  declaration  5  3.3 

case  statement 

compound  statement  39  6 

compound  declaration 

deferred  declaration  6  3.3 

compound  statement 

un labeled  statement  37  6 

constant 

primary  27  5.3 

constant  declaration 

immediate  declaration  5  3.3 

constructor 

constant  29  5.3 
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dec (arat i on 


body  element 

3 

3.2 

deferred  declaration 

dec  1 arat i on 

4 

3.3 

generic  declaration 

69 

11.3 

definable  symbol 

function  declaration 

50 

7.2 

needed  i tem 

77 

11.4 

procedure  declaration 

48 

7.1, 

direct  type  declaration 

type  declaration 

19 

4.4.2 

exception  declaration 

immediate  declaration 

5 

3.3 

exit  statement 

9imple  statement 

38 

6 

expression 

actual  parameters 

53 

7.3 

allocation  statement 

24 

4.4.3 

array  constructor 

33 

5.6 

assertion 

8 

3.4 

assignment  statement 

40 

6.1 

attribute  inquiry 

25 

4.5.3 

case  statement 

43 

6.4 

constant  declaration 

16 

4.2.1 

express i on 

26 

5.2 

if  statement 

42 

6.3 

location  specification 

80 

12.3 

pr i mary 

27 

5.3 

range 

14 

4.1.7 

record  or  union  constructor 

32 

5.6 

referencing  form 

30 

5.3 

repeat  statement 

44 

6.5 

representational  item 

79 

12.2 

set  constructor 

34 

5.6 

subtype 

12 

4.1.6 

translation  time  property 

68 

11.1.2 

type 

10 

4.1.5 

variable  declaration 

15 

4.2.1 

waiting  Invocation 

64 

10.5 

formal  parameters 

abbreviation  declaration 

17 

4.4.1 

capsule  declaration 

54 

8.1 

direct  type  declaration 

20 

4.4.2 

function  declaration 

50 

7.2 

Indirect  type  declaration 

23 

4.4.3 
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procedure  declaration 
task  declaration 


48  7.1 

61  10.1 


forma  I 


abbreviation  declaration 

17 

4.4. 

capsule  declaration 

54 

8.1 

direct  type  declaration 

20 
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function  declaration 
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7.2 

indirect  type  declaration 
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needed  i tem 

77 

11.4 

procedure  declaration 

48 

7.1 

task  declaration 

61 

10.1 

function  declaration 

compound  declaration 


3.3 


function  invocation  primary 
constant 


23 


5.3 


generic  constraint 

generic  parameters 


70 


11.3 


generic  declaration 
dec  I arat ion 


3.3 


generic  parameters 

generic  declaration 


59 


11.3 


goto  statement 

simple  statement 
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guard  statement 

compound  statement  33 

if  statement 

compound  statement  3g 

Immediate  declaration 

declaration  4 


imports 

capsule  declaration 
function  declaration 
procedure  declaration 
task  declaration 
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50  7.2 

48  7.1 
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type  declaration  13  4.4.2 

location  specification 

variable  declaration  15  4.2.1 

needed  i tern 

needs  7G  11.4 

needs 

generic  declaration  68  11.3 

operation  generic  constraint 

generic  constraint  71  11.3 


pragmat 

pragmats  82  B 

token  separator  B  2.2 


pragmats 

pragmat  token  separator 


L  2.4.2 


primary 


express i on 

2E 

5.2 

referencing  form 

'  30 

5.3 

resolved  constant 

35 

5.7 

procedure  declaration 

compound  declaration 

7 

3.3 

procedure  Invocation  statement 

simple  statement 

38 

6 

raise  statement 

simple  statement 

38 

6 

range 

array  constructor 

33 

5.6 

case  statement 

43 

6.4 

referencing  form 

30 

5.3 

subtype 

12 

4.1 

record  or  union  constructor 

constructor 

31 

5.6 

referencing  form 
constant 
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5.3 
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var i ab 1 e 

28 

5.3 

region  statement 

compound  statement 

39 

5 

repeat  statement 

compound  statement 

39 

6 

representational  item 

representational  item 
representational  specification 

79 

78 

12,2 

12.2 

representational  specification 
direct  type  declaration 
indirect  type  declaration 

20 

23 

4.  A. 2 
4.4.3 

reraise  statement 

simple  statement 

38 

G 

resolved  constant 
constant 

29 

5.3 

return  statement 

simple  statement 

38 

G 

set  constructor 
constructor 

31 

5.G 

simple  statement 

un labeled  statement 

37 

G 

statement 

body  element 

3 

3.2 

subtype 

abbreviation  declaration 

17 

4.4.1 

attribute  inquiry 

25 

4.5.3 

constant  declaration 

1G 

4.2.1 

direct  type  declaration 

20 

4.4.2 

formal  parameters 

52 

7.3 

function  declaration 

50 

7.2 

indirect  type  declaration 

23 

4.4.3 

needed  i tem 

77 

11.4 

operation  generic  constraint 

74 

11.3.3 

repeat  statement 

44 

G.5 

resolved  constant 

35 

5.7 

subtype 

12 
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subtype  comparison 
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translation  time  property 

68 

11.1.2 

type 

10 

4.1.5 

value  generic  constraint 

75 

11.3.4 

variable  declaration 

15 

4.2.1 

subtype  comparison 

expression  2G  5.2 


subtyps  generic  constraint 

generic  constraint  71  11.3 


task  declaration 

ccnpound  declaration  7  3.3 


task  invocation  statement 

simple  statement  38  G 


translation  time  property 

actual  translation  time  properties  G7  11.1.2 

formal  translation  time  properties  66  11.1.2 


translat ion  uni  t 


type 


abbreviation  declaration 
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4.4.1 

formal  parameters 

52 

7.3 

function  declaration 

50 

7.2 

needed  i tem 

77 

11.4 

opr-ation  generic  constraint 

74 

11.3.3 

r ' jC " ved  constant 

35 

5.7 

subty,.  j 

12 

4.1.6 

eubtype  generic  constraint 

73 

11.3.2 

translation  time  property 

68 

11.1.2 

type 

10 

4.1,5 

type  comparison 

11 

4.1.5 

value  generic  constraint  . 

75 

11.3.4 

type  compa^  isr  * 

express  it.-. i 

26 

5.2 

type  declaration 

deferred  declaration 

6 

3.3 

type  generic  constraint 
generic  constraint 

71 

11.3 

un labeled  statement 
statement 

36 

6 
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user-def i nsd  subtype 

subtype  12 

user-defined  type 

type  10 

value  generic  constraint 

generic  constraint  71 

var i ab I e 

allocation  statement  24 

assignment  statement  40 

primary  27 

region  statement  55 

task  invocation  statement  52 

variable  declaration 

immediate  declaration  5 

visible  list 

capsule  declaration  54 

uait  statement 

compound  s  .cement  39 


S3 


4.1.6 


4.1.5 


11.3 


4.4.3 

6.1 

5.3 
10.7 
10.1 


3.3 


8.1 


6 


uaiting  Invocation 
wait  statement 
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Index 


# 

as  a  definable  symbol  13.1 
for  typ  ■  and  subtype  resolution  5.7 
user-defined  13.5 
&  C.7,  C.8 
**  C.3,  C.4 
*  C.3,  C.4 
+  C.3,  C.4 
-  C.3,  C.4 

case  range  value  label  6.4 
ENUM  4.3,  C.2 
INT  4.3,  C.3 
range  4.1.7 
.ALL  4.4.2 

accessing  dynamic  variables  4.4.3 
automatically  defined  for  user-defined  type  4.4.2,  4.4.3 
.TAG 

See  also  TAG 
/  C.4 

I 

as  a  terminator  3.2 
<  C.2,  C.3,  C.4,  C.8,  C.9 

=  C.l,  C.2,  C.3,  C.4,  C.5,  C.6,  C.7,  C.8,  C.9,  C.10,  C.l  1 

abbreviation  invocation  4.4.1 

abbreviation 

declaration  4.4.1 
invocation  4.4.1 
local  definitions  7.3 
overloading  1 1 
abnormal  function  7.2.1 
ABS  C.3,  C.4 
ACT  10.1,  C.10 

assignment  &  equality  14.5.1 
built-in  and  user-defined  14.5.2 
states  14.2.1 
activation  clock  10.4 
activation  10.1 
creation  of  10.1 
termination  by  exception  9,  9.3 
See  also  task  declaration 
ACTIVE  14.2.1,  C.10 
actual  generic  property 

See  also  formal  generic  property 
actual  interface  11 

See  also  formal  interface 
pragmats  for  B 
actual  parameters  7.3 

used  to  resolve  subtype  of  formal  parameter  4.1.1 
See  also  formal  parameters 
actual  signature  11 

See  also  formal  signature 
actual  translation  time  property  11,  11.1.2 

use  of  CONST  and  READONLY  formal  parameters  7.3 
ALL 

exporting  and  exposing  ALL  8.2 
importing  ALL  3.7 
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See  also  .ALL 
allocation  property  4.4.3 
allocation  statement  4.4.3 
side-effects  from  7.2.1 
AND  C.1.C.9 
arithmetic  operators  5.2 
array  constructor  5.6 
ARRAY  4.3,  C.7 
constructor  5.6 
dimension  inquiry  4.5.1 
ASCII  C.15 

95  character  set  2.1 
corresponding  enum  literals  2.3.8 
assembly  language 

See  also  foreign  code 
assertion  3.4 

placement  in  body  3.2 

See  also  type  and  subtype  inquiry 
assignable  type  4.3 
ACT  C.10 
ARRAY  C.7 
BOOL  C.1 

constructors  for  5.6 
ENUM  C.2 
FLOAT  C.4 
INT  C.3 
MAILBOX  C.11 
RECORD  C.5 

required  for  messages  10.3 
SET  C.9 
STRING  C.8 
UNION  C.6 

See  also  assignment,  nonassignable  type 
assignment  statement  6.1 
assignment 

as  a  definable  symbol  13.1 
assignable  type  4.3 
assignment  statement  6.1 

automatically  defined  for  user-defined  type  4.4.2,  4.4.3 
CONST  and  OUT  parameters  7.3 
initialization  4.2.1 
of  mailboxes  14.1,3 

sharing  assignment  for  indirect  types  4.4.3 
user-defined  13.2 
associativity  5.2 
attribute 

inquiry  4.5.3 
available  names  3.5 
begin  statement  6.2 
binding  7.3 

See  also  formal  parameters 
block 

See  also  begin  statement 
body  element  3.2 
body  3.2 

local  definitions  3.3,  4.2.1,  6,  9.1 
BOOL  4.3,  C.1 

expression  used  in  assert  statement  3.4 
expression  used  in  if  statement  6.3 


INTERMETRICS  INC. 


Index 


273 


expression  used  in  WHILE  form  of  repeat  statement  6.5 
literal  2.3.9 

used  as  generic  parameter  and  as  element  in  Interface  11.3.4 
used  in  manifest  expressions  5.5 
capsule  invocation  declaration  8 
capsule 

as  separate  translation  unit  3.1 
configuration  12 
declaration  8 
local  definitions  7.3 
overloading  1 1 
returning  from  6.7 
separate  translation  of  8.1 
uses  of  4.4,  8,  8.2 
case  statement  6.4 

conditional  translation  5.5 
user-defined  types.  In  13.6 
character  set  2.1 

95  to  55  conversion  2.3.1,  2.3.3,  2.3.4,  2.3.6,  2.3.7,  2.3.8 
clock  10.4 
CLOSE  A.l,  C.14 
CLOSED  pragmat  B 
closed  scope  3.5 

abbreviation  declaration  4.4.1 
capsule  declaration  8 
deferred  declarations  3.3 
function  declaration  7.2 
procedure  declaration  7.1 
task  declaration  10.1 
type  declaration  4.4.2 
CNVT  A.3 
comment-  2.4.1 
common  data  pools  8.1 
component  selection  4.3,  5.3 

automatically  defined  for  user-defined  type  4.4.2,  4.4.3 
compound  declaration  3.3 
capsule  declaration  8 
function  declaration  7.2 
procedure  declaration  7.1 
task  declaration  10.1 
See  also  body 
compound  statement  6 
begin  statement  6.2 
case  statement  6.4  * 
guard  statement  9.2 
if  statement  6.3 
local  definitions  6,  6.5 
repeat  statement  6.5 
reraise  statement  9.4 
See  also  body 
concatenation  5.2 
See  also  & 

conditional  message  passing  14.1.2 
conditional  translation  5.5 
COND_LOCK  14.4.3,  C.13 
C0ND_RECE1VE  14.1.2,0.11 
COND_SEND  14.1.2,0.11 
configuration  capsule  12 
conflicting  definitions  3.5,  11.1,  11.3 
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conjunction 

See  also  AND 
CONST  binding  7.3 

restriction  4.1.1,  4.4.2,  7.2.1,  13.2,  13.3 
constant  declaration  4.2.1 
pragmats  for  B 
constant  4.2,  4.2.1,  5.3 
as  data  item  5.1 
manifest  expression  5.5 
specifying  a  subtype  for  4.1.1 
underlying  constant  of  user-defined  type  4.4.2 
constraint  property  4.1,  4.1,2 
constructor  5.4, 5.6 
user-defined  5.7,  13.5 
CREATE  10.1 
scheduling  of  14.2.3 
critical  activation  14.2.2 
critical  areas  14.2.2 
CRITICAL  C.10 
pragmat  for  B 
dangerous  sharing  10.6 
pragmat  for  B 
data  item  4.1,  4.2 
D AT A_LOCK  1 0.7,  1 4.4.2,  C.  1 2 
declaration  3.3 

See  also  deferred  declaration,  immediate  declaration 
deferred  declaration  3.3 
abbreviation  4.4.1 
abbreviation  declaration  4.4.1 
capsule  declaration  8 
formal  interface  11.1 
function  declaration  7.2 
generic  replication  of  11.3 
overloading  1 1 
placement  in  body  3.2 
pragmats  for  B 
procedure  declaration  7.1 
task  declaration  10.1 
type  declaration  4.4.2 
deferred  unit  3.3 

forward  reference  to  3.6 
definable  symbol  13.1 
defined  variable  4.2 
as  data  item  5.1 
definition  3.5 
declaration  3.3 
forma!  parameter  7.3 
generic  parameter  11.3 
goto  label  6 

index  of  a  repeat  statement  6.5 
matching  identifier  6 
result  variable  7.2.1 
DELAYJJNTIl  C.10 

DELAY_UNT!I _ INACTIVE  C.10 

dereference 

See  also  indirect  type  declaration 
direct  type  declaration  4.4.2 
disjunction 

See  also  OR 
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DIV  C.3 

dot  selection  5.3 

as  a  definable  symbol  13.1 
user-defined  13.4 
dynamic  variable  4.4.3 
as  data  item  5.1 
elaboration  3.1 
empty  body  3.2 
EMPTY  14.1.1 
EMPTY_SLOTS  C.ll 
ENUM  4.3,  C.2 

components  of  text  files  A.1 
expression  used  in  components  of  text  files  A.3 
expression  used  in  FOR  form  of  repeat  statement  6.5 
literal  2.3.7 

used  as  generic  parameter  and  as  element  In  Interface  11.3.4 
used  in  manifest  expressions  5.5 
used  in  strings  2.3.8 
EOF  A.2,  C.  1 4 
equality 

of  indirect  types  4.4.2 
of  mailboxes  14.1.3 
of  subtypes  4.1.6,  4.5.1 
of  types  4.1.5,  4.5.2 
See  also  = 
error 

See  also  exception,  translator  warnings 
exception  declaration  9.1 
exception  9.1,  D 
X=SUBTYPE  4.4.3 
X_ASSERT  3.4 
X_CASE  6.4 

X_EMPTY_MAILBOX  10.5,  C.l  1 
X_EOF  C.l  4 
X_FILE  C.l  4 
X_FILENAME  C.l  4 
X_FIIEP0S  C.l  4 
X_FORMAT  A.3 
X_FREE  4.4.3,  12.2 
X_ INIT  4.2.1,  7.2 
X_LN  C.l  4 
XJ.OCK  C.l  2 
X_MAXRANGE  C.3 
X_NEG_EXP  C.3 
X_NOFILE  C.14 
X_OVERFLOW  C.3,  C.4 
X_RANGE  C.2,  C.3,  C.4,  C.6 
X_SUBSCRIPT  C.7,  C.8 
X_SUBTYPE  7.3,11.3.2 
X_TAG  C.6 
X_UNHANDLED  9.3 
X_ZERO_DIVIDE  C.3,  C.4 
EXCESS-LOCKS  14.4.2,  C.l 2 
exclusive  disjunction 
See  also  XOR 
exit  statement  6.6 

See  also  matching  identifiers 
explicit  overloading  11.2 
exports  8.2 
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hiding  representation  4.4.2,  4.4.3 
See  also  capsule  declaration  • 

EXPOSE  8 
expression  5.2 

attribute  inquiry  4.5.3 
exceptions  raised  by  9.3 
See  also  manifest  expression,  operator  symbols 
EXTERMINATE  C.10 
ignored  in  critical  areas  14.2.2 
external  capsules  8,1 
FILE  A.1.C.14 
file  processing  A.2 
text  files  A.3 
FILE_RENAME  A.2 
finalization 

automatic  for  new  types  13.3 
FIXED  4.3 
FLOAT  4.3,  C.4 

conversions  to/from  text  files  A.3 
literal  2.3.6 

used  as  generic  parameter  and  as  element  in  interface  11.3.4 
used  in  manifest  expressions  5.5 
FLOOR  C.4 

for  form  of  repeat  statement  6.5 
for  variable 

See  also  repeat  index 
foreign  code  12.4 
formal  interface  11 
pragmats  for  B 
representation  restriction  12.2 
formal  parameters  7.3 
CONST  7.3 
OUT  7.3 
READONLY  7.3 

specifying  a  type  or  subtype  for  4.1.1 
VAR  7.3 
See  also  aliasing 
formal  signature  11 

formal  translation  time  property  11,  11.1.2 

FORMAT  A.3 

forward  reference  3.6 

FREE  4.4.3 

FULL  14.1.1 

FULL_:SLOTS  C.ll 

See  also  side-effects 
•function  invocation  primary  7.2 
actual  signature  11.1.1 
function  result  variable 

See  also  result  variable 
function 

as  generic  parameter  and  as  element  in  interface  11.3.3 
as  needed  name  11.4 
declaration  7.2 
formal  signature  11.1.1 
local  definitions  7.2,  7.3 
overloading  11 
returning  from  6.7 
garbage  collection  4.4.3 
generic  constraint  11.3 
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generic  declaration  1 1.3 
local  definitions  11.3 
generic  overloading  1 1.3 
generic  parameters  11.3 
local  definitions  1 1.4 
goto  label  5 

forward  reference  to  3.6 
goto  statement  6.8 
See  also  goto  label 
guard  statement  9.2 
guarded  body  9.2 
handler  9.2 

handling  an  exception  9,  9.3 
I/O  conversions  A.3 
I/O  formatting  A.3 
I/O 

high-level  A 
low-level  14.6 
side-effects  from  7.2.1 
identifier  2.3.4 
as  a  name  3.5 
if  statement  6.3 
conditional  translation  5.5 
IFLOAT  C.3 

immediate  declaration  3.3 
capsule  declaration  8 
capsule  invocation  declaration  8.1 
constant  declaration  4.2.1 
exception  declaration  9.1 
placement  in  body  3.2 
variable  declaration  4.2.1 
interrupt  14.1.4 
imports  3.7 

See  also  capsule  declaration,  function  declaration,  procedure  declaration,  task 
declaration 

IN  C.9 
index  variable 

See  also  repeat  index 
INDEXOF  4.5.1,  C.7 

indirect  modification  of  variables  treated  as  constants  4.2 

indirect  type  declaration  4.4.3 

indirect  variable  4.4.3 

infix  operator  5.2 

inheritance  11.1 

initialization 

automatic  for  new  types  13.3 
automatic  initialization  for  files  A.1 
automatic  initialization  for  indirect  variables  4.4.3 
automatic  initialization  for  multitasking  types  10.1,  10.3,  10.4,  10.7 
optional  for  dynamic  variables  4.4.3 
optional  for  variables  4.2.1 
required  for  constants  4.2.1 
See  also  assignment 
INT  4.3,  C.3 

expression  used  in  FOR  form  of  repeat  statement  6.5 
literal  2.3.6 

used  as  generic  parameter  and  as  element  in  interface  11.3.4 
used  in  manifest  expressions  5.5 
interface  11,  11.1 
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matching  rules  11.1 

See  also  actual  interface,  formal  interface,  generic  property,  signature 
interrupt  14.1.4 
intersection  of  sets 
See  also  AND 
invocation 

actual  interface  11.1 
of  abbreviation  4.4.1 
of  capsule  3.1,  8 
of  function  7.2 
of  procedure  7.1 
of  task  10.1 
of  type  4.4.2 
pragmats  for  B 
terminated  by  exception  9,  9.3 
known  in  a  scope  3.5 
label 

See  also  goto  label,  matching  identifiers 
LATCH  14.4.3,  C.  13 
lifetime  4.2 

data  modified  by  function  7.2.1 
of  defined  variables  and  constants  5.1 
of  dynamic  variables  4.4.3,  5.1 
of  local  variables  of  a  capsule  8.1 
of  task  10.1 
line  of  a  file  A.3 
line  of  input  text  2.2 
LIST  pragmat  B 
literal  2.3.5, 5.4 
manifest  5.5 
user-defined  5.7,  13.5 
local  names  3.5 
location  12.3 
LOCK  14.4.3,  C.  12,  C.  13 
logical  operators  5.2 
LOW_SYNCH_AWAIT  14.5.2 
LOW_SYNCH_RE$ET  14.5.2 
LOW_SYNCH_$  IGNAL  14.5.2 
LOW_SYNC_RESET  C.10 
LOW_SYNC_S  IGNAL  C.10 
LOW_SYNC_WAIT  C.10 
LOW_T ASK_END  14.5.2,  C.10 
machine-dependent 

configuration  capsule  12 
foreign  code  12.4 
location  12.3 
representation  12.2 
MAILBOX  10.3,  C.  11 

assignment  and  equality  14.1.3 
conditional  message  passing  14.1.2 
functions  relating  to  14.1.1 
used  for  interrupts  14.1.4 
main  activation  10.1 
main  capsule  3.1 
manifest  expression  5.5 

used  as  generic  parameter  and  as  element  in  interface  11.3.4 
matching  identifiers  6 
ME  10.2,  14.5.2,  C.10 
message  passing  10.3 
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MOD  C.3 
mutual  exclusion 

See  also  region  statement 
name  scope 

See  also  scope 
name 

definition  of  3.5 
exporting  of  all  8.2 
forward  reference  to  3.6 
importing  of  variable  name  3.7 
use  of  3.5 

See  also  conflicting  definitions,  definition 
needs  11.4 
NIL  2.3.10,  4.4.3 

Nil _ ACT  14.5.1 

nonassignable  type  4.3 
DATA_10CK  C.12 
FILE  C.14 
LATCH  C.13 

noncritical  activation  14.2.2 
NONCRITIC  AL  C.10 
N0NRECURS1VE  pragmat  B 
normal  function  7.2.1 
NOT  C.1.C.9 
numeric  literal  2.3.6 
OK  pragmat  B 
OPEN  pragmat  B 
open  scope  3.5 
body  3.2 

compound  statement  6 
generic  declaration  11.3 
OPEN  A.1.C.14 

operation  generic  constraint  11.3.3 
operator  precedence 

See  also  precedence 
operator  symbol  2.3.2 

as  a  definable  symbol  13.1 
as  a  name  3.5,  7.1,  7.2 
user-defined  13.2 
optimization 

by  avoiding  garbage  collection  4.4.2 
by  restricting  formal  parameters  to  subtypes  4.5 
by  suppressing  exceptions  2.4.2 
of'CONST  formal  parameters  7.3 
of  normal  functions  7.2.1 
OPTIMIZE  pragmat  B 
OR  C.l,  C.9 
ordering 

See  also  < 

OUT  binding  7.3 

aliasing  warning  4.1.1 
restriction  4.1.1,  8,  13.2,  13.3 
overloading  1 1 
explicit  11,  11.2 
generic  1 1,  1 1.3 
name  conflict  resolution  11.1 
OWNER  14.4.2,  C.12 
parameter 

See  also  actual  parameter,  forma!  parameter 
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parenthesized  expression  5.3 
manifest  expression  5.5 
pattern  declaration  H.3 
physical  file  A.l 
pointer 

See  also  indirect  type  declaration 
POS  C.2 

POSITION  A.2,  C.14 
pragma f  2.4.2,  B 
precedence  5.2 
PRED  C.2,  C.3 
prefix  operator  5.2 
primary  5.3 
PRIORITY  10.2,  C.  10 
no  preemption  in  critical  areas  14.2.2 
See  also  scheduler 
procedure  invocation  statement  7.1 
actual  signature  11.1.1 
procedure 

as  generic  parameter  and  as  element  in  interface 
as  needed  name  11.4 
declaration  7.1 
formal  signature  11.1.1 
local  definitions  7.3 
overloading  M 
returning  from  6.7 
program  3.1 
raise  statement  9.3 
raising  an  exception  9 
random  file  A.1 
range  value  label  6.4 
range  4.1.7 

mNIM  FK)AT' IMr'  ra"ee  value  l3bel 
READLN  A.3,  C.14 
READONLY  binding  7,3 
restriction  4.1.1,  7.2.1,  10.1,  13.3 
readonly 

as  data  item  5,1 
exporting  8.2 
exposing  8.1 
importing  3.7 
real-time  clock  10  4 
RECEIVE  10.3,  C.  11 
RECE 1  VE_COMPLETE  C.  1 1 
RECEIVE_REQUEST  C.ll 
RECEIVE_REVOKE  C.ll 
RECEiVE_ST  C.ll 
RECEIVE.TEST  C.ll 
record  or  union  constructor  5.6 
RECORD  .4.3,  C.5 
constructor  5.6 
RECURSIVE  pragma!  B 
referencing  form  5.3 
region  statement  10.7 
semantics  of  14.4.1 
rejoin  of  activations  10.1 
relational  operators  5.2 
repeat  index  6,5 
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repeat  statement  6.5 

user-defined  types  in  13.7 
replacement  element  11.3 
replication 

See  also  generic  declaration 
representational  item  12.2 
representational  specification  12.2 
reraise  statement  9.4 

See  also  raise  statement 
reserved  words  2.3.1 
resolution  of  types  and  subtypes 
resolved  constant  5.7 
resolved  constant  5.7 
result  variable  7.2 
return  statement  6.7 
subtypes  4.1.6 
types  4.1.5 
scheduler 

built-in  10,  10.2 
scheduling  algorithm  14.2.3 
user-defined  14.5 
scope  3.5 

See  also  closed  scope,  open  scope 
selection 

See  also  dot  selection,  subscripting 
SEND  10.3,14.1.2,0.11 
SEND_COMPLETE  C.l  1 
SEND_REQUEST  C.ll 
SEND_REVOKE  C.ll 
SEND_ST  C.11 
SEND_TEST  C.ll 
separate  translation 
capsule  declaration  8 
sequential  file  A.l 
set  constructor  5.6 
SET  4.3,  C.9 
constructor  5.6 
set  operands  5.2 
SET_POSIT!ON  A.2,  C.l 4 
SET_PRIOR!TY  10.2,  C.10 
shared  variable  10.6 

use  of  CONST  and  READONLY  formal  parameters  7.3 
short  circuiting 

See  also  AND,  OR 
side-effects  7.2.1 
signature  11,11.1.1 
simple  statement  6 

allocation  statement  4.4.3 
assignment  statement  6.1 
exit  statement  6.6 
goto  statement  6.8 
procedure  invocation  statement  7,1 
raise  statement  9.3 
return  statement  6.7 
task  invocation  statement  10.1 
single  value  label  6.4 
SIZE  A.2,  C.14 
SIZELN  A. 3,  C.14 
special  symbols  2.3.3 
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standard  file  A.l 
statement  6 

allocation  statement  4.4.3 
assignment  statement  6.1 
begin  statement  6.2 
case  statement  6.4 
exit  statement  6.6 
goto  statement  6.8 
if  statement  6.3 
placement  in  body  3.2 
procedure  invocation  statement  7.1 
raise  statement  9.3 
region  statement  10.7 
repeat  statement  6.5 
reraise  statement  9.4 
return  statement  6.7 
task  invocation  statement  10.1 
wait  statement  10.5 
STRING  4.3,  C.8 
literal  2.3.8 

used  as  generic  parameter  and  as  element  in  interface  11.3.4 
used  in  manifest  expressions  5.5 
See  also  ENUM 
subscripting  5.3 

as  a  definable  symbol  13.1 
user-defined  13.4 
subtype  comparison  4.1.6 
subtype  equality  4.5.1 
subtype  generic  constraint  11.3.2 
subtype  inquiry  4.5.1 
subtype  4.1,  4.1.6 
abbreviating  4.4.1 

as  generic  parameter  and  as  element  in  interface  11.3.2 

attribute  inquiry  4.5.3 

brief  description  4.3 

equality  4.1.6,  4.5.1 

inquiry  4.5.1 

of  user-defined  4.4.2 

relation  to  type  4.1.3 

resolution  in  manifest  expression  or  constructor  5.7 
specifying  4.1.2 

underlying  subtype  of  user-defined  subtype  4.4.2 
use  of  4.1.1 
SUBTYPEOF  4.5.1 
SUCC  C.2,  C.3 
SUPPRESS  pragmat  B 
SUSPEND  14.2.1,  C.10 
SUSPENDED  14.2.1,  C.10 
SYNCH_AWAIT  14.5.2 
SYNCH_RESET  14.5.2 
SYNCH_SIGNAL  14.5.2 
SYNC_RESET  C.10 
SYNC_S1GNAL  C.10 
SYNC_WA1T  C.10 
SY$_IN  A.3 
SY$_OUT  A.3 
tag 

See  also  UNION 
user-defined  14.5.3 
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See  also  activation 
task  invocation  statement  10.1 
actual  signature  11.1.1 
task 

as  generic  parameter  and  as  element  in  interface  11.3.3 
as  needed  name  11.4 
formal  signature  It. 1.1 
local  definitions  7.3 
overloading  1 1 
returning  from  6.7 
TASK_END  14.5.2,  C.10 
TASK_START  C.10 
as  data  item  5.1 
terminator  ;  3.2 
text  file  A.l,  A.3 
text  2.1 
TIME  C.10 

token  separator  2.2,  2.4 
token  2.2 

translation  environment  3.1 
all  generic  properties  11.1.2 
all  interface  matching  11.1 
translation  time  property  11,  11.1.2 
translation  unit  3.1 
translation-time  known 

all  manifest  expressions  5.5 
all  type  checking  4.1.1,  7,3 
all  type  properties  4.1 
some  constraint  properties  4.1 
translator  errors 

See  also  exception 
translator  warnings 

from  assertion  statement  3.4 
from  dangerous  sharing  10.6 
from  exceptions  always  being  raised  9.3 
type  checking  4.1.1,  7.3 
type  comparison  4.1.5 
overloading  11 
type  equivalence  4.1.5 
type  generic  constraint  11.3.1 
type  inquiry  4.5.2 
type  property  4.1,  4.1.2 
type  4.1,  4.1.5,  4.4.2 
abbreviating  4.4.1 

as  generic  parameter  and  as  element  in  interface  11.3.1 

brief  description  4.3 

declaration  4.4.2 

equality  4.1.5, 4.5.2 

inquiry  4.5.2 

local  definitions  7.3 

relation  to  subtype  4.1.3 

representation  12.2 

resolution  in  manifest  expression  or  constructor  5.7 
specifying  4.1.2 

underlying  type  of  user-defined  type  4.4.2 
use  of  4.1.1 
user-defined  4.4.2 
TYPEOF  4.5.2 

underlying  subtype  or  type  4.4.2 
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underlying  variable  or  constant  4A2 
See  also  .ALL 
union  of  sets 
See  also  OR 
UNION  4.3,  C.6 
conditional  translation  5.5 
constructor  5.6 
See  also  assignment 
unlabeled  statement  6 
UNLOCK  14.4.3,  C.  12,  C.  13 
UNSUSPEND  14.2.1,  C.10 
use  of  a  name  3.5 
user-defined  subtype  4.4.2 
user-defined  type  4.4.2 
used  in  case  statement  13.6 
used  in  repeat  statement  13.7 
restriction  4.4.1,  4.4.3 
value  generic  constraint  11.3.4 
manifest  expressions  5.5 
value  labels  6.4 
VAR  binding  7.3 

restriction  4.1.1,  10.1,  13.3 
variable  declaration  4.2.1 
pragmats  for  B 
variable  4.2,  5.3 
dynamic  4.4.3 
importing  variables  3.7 
indirect  4.4.3 
location  12.3 

passed  to  VAR  and  OUT  forma!  parameters  7.3 
readonly  5.1 
shared  10.6 

side-effects  from  modification  7.2.1 
specifying  a  subtype  for  4.1. ! 
underlying  variable  of  user-del  pe  4.4.2 
See  also  closed  scope 
variant  record 

See  also  UNION 
wait  statement  10.5 

avoiding  busy  waiting  10.3 
expansion  of  14.3.3 
WAITING  function  1 4.2. 1 ,  C.  1 0 
waiting  invocation  10.5 

synchronizing  operations  for  14.3.1 
waiting 

for  space  in  mailbox  for  message  10.3 
for  unlocking  of  region  10.7 
latches  using  busy  waiting  14.4.3 
wait  statement  10.5 
warning 

See  also  translator  warnings 
while  form  of  repeat  statement  6.5 
WRITE  A.2.C.14 
WRITELN  A.3,  C.14 
XOR  C.1,  C.9 
X_ASSERT  3.4 
X_CASE  6.4 

X_EMPTY_MA1LB0X  10.5,0.11 
X_E0F  C.14 
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X-FILE  C.14 
X_FILENAME  C.14 
X_FILEPOS  C.14 
X_FORMAT  A.3 
X_FREE  4.4.3,  12.2 
X_1NIT  4.2.1,  7.2 
X_LN  C.14 
X_LOCK  C.12 
X_MAXRANGE  C.3 
X_NEG_EXP  C.3  . 

X_NOFILE  C.14 
X_OVERFLOW  C.3,  C.4 
X_RANGE  C.2,  C.3,  C.4,  C.6 
X_SUBSCRIPT  C.7,  C.8 
X_SUBTYPE  4.4.3,7.3,11.3.2 
X_TAG  C.6 
X_UNHANDLED  9.3 
X_ZERO_DIVIDE  C.3,  C.4 


